Cameleer 0.6.1: the HTTP stack on simoom

Cameleer 0.6.1: the HTTP stack on simoom

Cameleer's HTTP server and HTTP client now run on simoom, the std-only
HTTP engine of the Cameleering family. The server uses an event loop per core instead of a thread per
connection; the client pools connections, multiplexes HTTP/2 and streams bodies. The release also carries
the entry for the official MCP Registry.

Breaking, in a patch number: the http2 cargo feature is gone, response header names are lower case,
and the HTTP clients refuse to turn certificate verification off. Read Upgrading before you
pull. (The MCP Registry checks published artifacts, and crates.io never changes a published version, so the
registry entry needed a new version number; this release is that version.)

What's new

The HTTP server runs on simoom

• An event loop per core serves plain HTTP and HTTPS (TLS 1.2 and 1.3, client certificates) for
  platform-http, http, the REST DSL, the MCP endpoint, the dev console and the emulators.

• A route starts on a pool of threads and moves to the loop when its handler proves fast: 126 of
  128 calls under 1 ms. It goes back when it stalls the loop. A handler that never blocks (the MCP
  endpoint) answers from any thread through a responder, with no thread waiting.

• Measured on DigitalOcean c-4 machines, the previous server against this one, same machines and rounds,
  three rounds in all:

  scenario	requests per second	p99 latency	CPU per request	threads
  http, 64 connections	1.33x	2.05 to 0.75 ms	30 to 16 µs	67 to 4
  http, 256 connections	1.56x	7.06 to 2.67 ms	31 to 16 µs	202 to 4
  rest-json, 64	1.31x	2.61 to 1.25 ms	37 to 20 µs	67 to 4
  mcp-session, 64	1.37x	5.64 to 3.18 ms	83 to 46 µs	147 to 71

  Peak memory is about half. The report, the raw data and the two earlier rounds, including the round
  where MCP was slower (0.88x) and why, are in
  docs/design/simoom-adoption.md.

The HTTP client runs on simoom-client

• The http and https producers, HttpClient and everything built on it (MCP, SaaS, datastore, FHIR and
  DICOMweb clients) use one shared client per set of settings: HTTP/1.1 keep-alive pooling, HTTP/2
  multiplexing, proxies, redirects and streamed request and response bodies.
• httpVersion=HTTP/2 works in every build, also with a streamed body.
• The Camel exceptions and messages are unchanged: connection refused, read timeout, TLS certificate errors.
  A plain http:// request to a TLS port reports "Connection closed unexpectedly: the answer is not HTTP".

The cameleer crate and the MCP Registry entry

• cargo install cameleer installs the cameleer command and cargo add cameleer gives the
  cameleer-main API (first published with 0.6.0).
• server.json, the mcp-name line in the crate README and the image label are the entry for the official
  MCP Registry.

Upgrading

• --features http2 is now an error: drop it. HTTP/2 is part of every build.
• Certificate verification cannot be turned off in the HTTP clients. hostnameVerification=false,
  insecureSkipVerify and trustAllCertificates on the http and https producers (and on the
  components that use HttpClient) are refused with a message that says what to do: trust a private server
  with trustStore, or set serverName to the name in its certificate. The AWS, Azure and Google Cloud
  components keep their own client and their trustAllCertificates for now.
• Response header names are lower case, as HTTP allows. Code that compares them case-sensitively
  must compare without case.
• An HTTP/1.0 client gets an HTTP/1.1 status line. It still gets a body with a length, never chunked.
• The server refuses requests that are ambiguous or malformed: request-smuggling shapes, and | and
  other unsafe bytes in the request target. The HTTP client now percent-encodes those bytes like curl and
  Java's client do.
• ServerConfig.pool_size (Rust API) now limits the threads for routes that block, not connections.
• Images: cameleering/cameleer on Docker Hub and ghcr.io/cameleering/cameleer, as in 0.6.0, with the
  new tags 0.6.1, 0.6, latest, 0.6.1-health and health.

Measured

• The tables above are simoom's gain over the previous Cameleer server. They are not a comparison with
  Apache Camel: that comparison is in the 0.6.0 notes and docs/BENCHMARKS.md.
• Binary size: the full build grows 1.7% (25.73 to 26.17 MB, Linux dist), the core build 7.4%
  (6.01 to 6.45 MB), measured with the old code still in place.
• Tests: the hermetic suite (cargo test --workspace) passed 2,971 tests with 0 failures on Windows 11
  and passes in CI on Linux and Windows, with zero build warnings.

Limits

• Not run for this release: the live-server, official-client and simulator test tiers, which need
  root in WSL. They matter most for the new client; the hermetic suite is what stands behind it.
• Still on the old code: WebSocket, the gRPC server and the HTTP/2 server and client under it, and the
  AWS, Azure and Google Cloud components' HTTP client. They move in later releases.
• A route that is fast for 126 of 128 calls and then blocks stalls one event loop until the server moves
  it back to the pool; a route that blocks on a request to its own server can hang a loop for that call.
• Release archives: attached to this release for Linux x86-64, Windows x86-64 and macOS arm64, in the
  general and the health (cameleer-health-...) distribution, each with a SHA-256 checksum, a CycloneDX SBOM
  and a Sigstore (cosign) signature bundle. This is the first release that has them; the signatures have not
  been verified by anyone outside the build yet.

Full list of changes: CHANGELOG.md.

Cameleer 0.6.0: packs, the health pack, and attestation

Cameleer 0.6.0 adds packs: optional, industry-specific sets of components with their own
version. The first is the health pack: HL7 v2, MLLP, FHIR R4, and new DICOM support. Apache
Camel has no DICOM component. This release also serves existing routes as MCP tools with no
edits and adds attestation in confidential VMs. The project now lives in the GitHub
organization Cameleering.

Breaking: HL7, MLLP and FHIR left the default build and image. If you use them, read
Upgrading before you pull.

What's new

The health pack (cameleer-health 0.6.0)

• HL7 v2 and MLLP: the mllp component, the hl7 data format and the hl7terser language.
  These moved from the default build.
• FHIR R4: the fhir component and the fhirJson and fhirXml data formats. These also
  moved from the default build.
• DICOM (new):
  • dicom component: DIMSE over TCP and TLS. It works as an SCP and as an SCU for C-ECHO,
    C-STORE, C-FIND, C-MOVE and C-GET.
  • dicomweb component: STOW-RS, QIDO-RS and WADO-RS, as a client and as a server.
  • Data formats: dicom, which converts Part 10 files and back, byte for byte, and
    dicomJson.
  • De-identification: dicomDeidentify applies the PS3.15 Annex E basic profile and its
    options. It is deterministic under a key and writes audit records to a hash-chained log.
  • Expressions: ${dicom.*} in Simple, and the dicom language.
• Getting it: the image cameleering/cameleer:health, or --features health. The pack costs
  about 2 MB of binary (30.91 MB against 28.99 MB for the Linux dist build).
• DICOM Conformance Statement: a
  PS3.2 conformance statement.
  Its tables are generated from the code and checked by a test.
• Pack information at run time: cameleer version, /q/info and /q/dev/packs show which
  packs a build contains.
• For Rust users: packs plug in through cameleer_core::pack and Main::add_pack.

Guides: the health pack,
DICOM,
healthcare overview.

Existing routes as MCP tools: --mcp-expose

cameleer run orders.camel.yaml --mcp-expose rest:* serves routes to MCP clients without
changing the route files:

• REST DSL operations become tools, with typed arguments taken from their documented parameters.
• direct: routes and route:<id> routes take a body and headers.
• GET operations are read-only. Writes need approval by default.
• Every call goes through the tool envelope.
• Overrides per route accept every ai-tool option.

See the MCP server guide.

Attestation in confidential VMs (cameleer-attest, in the default build)

Set camel.attestation.enabled=true inside one of these:

• an Intel TDX guest (Linux configfs-tsm);
• an AMD SEV-SNP guest (Linux configfs-tsm);
• a dstack CVM.

Cameleer then serves hardware evidence at /q/attestation. The evidence is bound to:

• the client's nonce;
• the server's TLS key;
• a manifest of the routes, the configuration (without secrets) and the tools;
• a hash-chained log of later changes to them.

MCP clients get the same evidence in the handshake _meta. With
camel.attestation.mcp-tool=true they can also get it as a tool. Start-up fails if attestation is
on and no evidence can be produced. See the
attestation guide and
cameleer.ing/trust.

Fixes and behaviour changes

• One port for HTTPS routes and the management endpoints: with
  camel.server.sslEnabled=true, HTTPS routes, /q/*, /q/attestation and MCP share one port.
  Before, start-up failed. Camel's separate management port (camel.management.*) is supported too.
• Changed: onException and doCatch for Exception now catch CamelExchangeException and
  the kinds under it, such as HttpOperationFailedException and ValidationException. They
  were missed because the exception was listed as its own parent. This matches Camel. A route
  whose Exception handler used to let these failures through now handles them.
• Changed: route configurations apply whatever the file order. Top-level onException,
  intercept and interceptSendToEndpoint, and a routeConfiguration without id, now apply to
  every YAML route. Before, they applied only to routes in files loaded after them.
• cameleer validate checks routeConfigurationId across files: a configuration in a later
  file is accepted, and an unknown id is an error.
• /q/metrics sends one Content-Type header.
• Readiness: a suspended consumer is reported as DOWN in the details too.

Distribution

• Images: cameleering/cameleer on Docker Hub, and ghcr.io/cameleering/cameleer, for
  linux/amd64 and linux/arm64, with the health variant next to the general image.
• Release archives are not part of 0.6.0. The archive workflow ran for the first time on the
  v0.6.0 tag and failed on all six jobs (a script without the execute bit, and no zip in Git
  Bash on the Windows runner). Both are fixed, and a test run of the fixed workflow built all
  six archives. Signing happens only on a release tag, so the signed archives
  (cameleer-<version>-<target> and cameleer-health-<version>-<target>, each with a SHA-256
  checksum, a CycloneDX SBOM and a Sigstore cosign signature) arrive with the next release.
  Until then, use the images or cargo install cameleer-main.

Upgrading

• Images moved. Pull cameleering/cameleer (Docker Hub) or ghcr.io/cameleering/cameleer.

  • Tags: latest, 0.6.0, 0.6, health, 0.6.0-health, 0.6-health, and edge for manual
    builds.
  • The old paths pmsudhi/cameleer and ghcr.io/pmsudhi/cameleer stop at 0.5.1 and get no
    new tags. Update your Dockerfiles, Compose files, Helm values and Kubernetes manifests.

• HL7, MLLP or FHIR users: switch to one of these:

  • cameleering/cameleer:health;
  • cargo install cameleer-main --features health;
  • for a smaller build, --no-default-features --features health plus the families you need.

  A route that uses one of these components in a build without the pack fails at start, and the
  message names the pack, the image and the feature.

• Rust users of the moved modules: there are no aliases.

  before	now
  cameleer_protocols::{hl7, mllp}	cameleer_health::hl7::{self, mllp}
  cameleer_soap::fhir	cameleer_health::fhir
  socket helpers in cameleer-protocols	cameleer_tls::net
  SOAP producer client	cameleer_http::client::EndpointClient
  now_utc	cameleer_core::util_time::now_utc

• Exception handling: check routes that rely on onException(Exception) not catching HTTP,
  validation or endpoint-resolution failures. Those failures are now caught.

• Route configurations in multi-file projects: a configuration now also applies to routes
  in files loaded before it.

• Source: the repository is
  github.com/cameleering/cameleer. The old GitHub URLs
  redirect, but update your git remotes.

Measured

• MCP tool calls: the comparison was rerun on 2026-11-12, all sides in one session, on
  DigitalOcean c-4 machines:

  	Cameleer	Apache Camel camel-mcp-server	official TypeScript SDK
  session tool calls per second	39,922	22,604	2,257
  memory	56 MB	289 MB	197 MB

  • Cameleer handles 1.77x Camel's tool calls per second and 17.7x the SDK's.
  • Camel's p99 latency is lower: 5.2 ms against 6.3 ms.
  • The SDK figure is higher than in 0.5.0 because the baseline moved to zod 4.

  The report and the raw data are in docs/BENCHMARKS.md.

• Health pack, live tier: CAMEL_HEALTH_INTEROP=1 passed 10 of 10 against these servers:

  • DCMTK 3.6.7, in both roles, with and without TLS;
  • Orthanc 1.12.2 with DICOMweb 1.16;
  • python-hl7 0.4.5, as an MLLP receiver and as a client;
  • the HAPI FHIR JPA server 8.12.0.

• DICOM files: 33 public pydicom test files are read and written back byte for byte.

• Tests: the hermetic suite (cargo test --workspace) passed 2960 tests with 0 failures on
  Windows 11 when the health pack was merged, with zero build warnings.

Limits

• Attestation hardware: attestation has not yet run on real TEE hardware. The tests use a
  simulated configfs-tsm directory and a simulated dstack agent.
• Attestation verification: Cameleer produces the evidence and the binding but does not verify
  Intel's or AMD's signature chain itself. A platform verifier, such as Intel Trust Authority,
  Microsoft Azure Attestation or dstack's verifier, does that.
• Health pack, not tested: cloud DICOM services (Azure, Google, AWS), dcm4che and real
  modalities.
• Health pack, not built: pixel codecs (JPEG, JPEG-LS, JPEG 2000, RLE), Storage Commitment,
  MPPS, and IHE ATNA audit messages. There is no visual channel editor and no importer for Mirth
  channels.
• Release archives: none for 0.6.0 (see Distribution). The fixed workflow has built unsigned
  archives on all three targets in a test run; the signing step has not run yet.

Full list of changes: CHANGELOG.md.

Cameleer 0.5.1

Fixed

• HTTP/2 client (gRPC): a complete response followed by RST_STREAM(NO_ERROR) is no longer
  reported as stream reset: NO_ERROR, as RFC 9113 section 8.1 requires (INTEROP bug 20).

The 0.5.0 release notes describe the action layer for AI agents: https://github.com/pmsudhi/cameleer/releases/tag/v0.5.0

Install: cargo install cameleer-main, or docker pull pmsudhi/cameleer:0.5.1.

Cameleer 0.5.0: the action layer for AI agents

Cameleer becomes an action layer for AI agents: any route can be a tool that agents call through
a reliability envelope (schema checks, deduplication, approvals, rate limits, timeouts that
cancel, compensation, a hash-chained audit log). Cameleer serves those tools as an MCP server
(both protocol eras, Streamable HTTP and stdio; official conformance 39/39 and 26/26), imports
other MCP servers' tools as a client and gateway, and runs tool-calling agents as a route step
with seven model components and 23 providers. Measured on the same cloud machines, its MCP
server handles 41,620 tool calls per second against 22,458 for Apache Camel's
camel-mcp-server and 1,536 for the official TypeScript SDK, in 53 MB against 317 MB and 214 MB
(report). In a field test of 40 real requests through Claude and the
official MCP client, Claude Opus 5.5 completed 157 of 160 runs correctly
(guide).

Added

• Routes as tools for AI agents (new crate cameleer-ai, new ai feature, in full):
  ai-tool, ai-resource and ai-prompt with Camel's option names and semantics, and a tool
  registry. Every call goes through a reliability envelope: JSON Schema 2020-12 checks of the
  arguments (with an error the model can act on), structured results, deduplication of tools
  with side effects, approval of destructive or matching calls, timeouts that cancel the
  tool's route, rate limits per principal, circuit breakers, compensation per conversation, a
  hash-chained audit log (camel.ai.audit.*), definition pinning (version,
  camel.ai.manifest) and a kill switch (camel.ai.disabled-tools). See
  ai-tool.
• MCP server with Camel's camel.server.mcp-* properties, serving those routes to MCP
  clients over Streamable HTTP and stdio (cameleer run --mcp, --mcp-stdio). It speaks
  2026-07-28 (stateless, server/discover, approvals as multi round-trip requests with a
  sealed requestState, subscriptions/listen, caching hints) and 2025-11-25, 2025-06-18 and
  2025-03-26 (sessions, elicitation/create approvals) on the same endpoint. Tools,
  resources, templates, prompts, completion, pagination and change notifications;
  authentication with API keys, JWTs or token introspection, with protected-resource metadata
  and audience checks. Tool routes can return images, audio and embedded resources
  (CamelAiToolContent). Checked with the official conformance suite
  (scripts/mcp-conformance.sh). See the MCP server guide.
• The agent step (Cameleer extension): a model and its tools in a loop, as one step of a
  route, with turn, token and time limits, conversation memory, approvals that pause the
  conversation until a person decides, and record/replay of model responses. See
  the agent step.
• Tool calling in every model component: openai (and its Camel 4.23 name llm),
  azure-openai, aws-bedrock (Converse), google-vertexai (Gemini) and the new
  anthropic component take Camel's tags, autoToolExecution, maxToolIterations,
  maxAgenticTokens and related options and run your ai-tool routes for the model.
• anthropic component for the Anthropic Messages API.
• openai/llm: streaming, the Responses API and Ollama's native API: streaming=true
  streams plain chats and every turn of the tool loop, passing text deltas to a
  streamingChunkProcessor bean while the body stays the whole answer; openai:responses
  uses OpenAI's Responses API; apiFormat=ollama calls Ollama's /api/chat. All three work
  with tags, the agent step and record/replay.
• cameleer test runs YAML test files: send messages, call tools, approve, compensate, and
  check bodies, headers, deduplication and mock endpoints, with models replayed from
  recordings.
• json-validator: JSON Schema 2020-12 keywords prefixItems, minContains,
  maxContains, dependentSchemas, unevaluatedProperties and unevaluatedItems.
• cameleer tool: the kill switch and approvals of a running integration from the command
  line (tool list, disable, enable, approvals, approve, deny), and GET /q/dev/tools
  with POST /q/dev/tools/{name}/disable|enable on the dev console. MCP clients get
  list_changed when a tool is withdrawn.
• Cooperative cancellation of an exchange (Exchange::set_cancel_token): once the token is
  set, the exchange and its copies stop before their next pipeline step.
• MCP client and gateway: camel.ai.mcp.NAME.* connects to MCP servers over HTTP or stdio
  (both protocol eras) and imports their tools into the tool registry, where they run through
  the same envelope (approvals, deduplication, rate limits, audit) and can be used by the agent
  step (tools: mcp:github), by model components with tags, and re-exported by Cameleer's own
  MCP server. Tool lists re-sync on list_changed and reconnects; a tool whose definition
  changes after it was pinned is withdrawn. The new mcp: component calls a server's tools,
  resources and prompts from a route. See the MCP client guide.
• Progress, logs, elicitation and sampling from tool routes: ai-tool:x?operation=progress,
  log, elicit and sample inside a tool route send MCP progress and log notifications, ask
  the client's user a question, or ask the client's model, in both protocol eras. The official
  conformance suite now passes every scenario (39 of 39 for 2025-11-25, 26 of 26 for
  2025-06-18).
• Tool guardrails on ai-tool: redact replaces secrets, e-mail addresses, card numbers
  (Luhn-checked), IBANs, SSNs, IPv4 addresses, phone numbers or custom patterns in results
  before they reach the model, the client or the audit log; authorize is a Simple predicate
  over the arguments and the caller; cacheTtl reuses results.
• gemini component for the Gemini API with API keys, with tool calling and thought
  signatures.
• Provider presets on openai/llm: provider=groq (or mistral, deepseek, xai,
  openrouter, together, fireworks, cerebras, perplexity, huggingface, dashscope,
  moonshot, cohere, nvidia, gemini, ollama, vllm, lmstudio, llamacpp) sets the
  base URL and the key's environment variable. OpenAI reasoning models get
  max_completion_tokens; DeepSeek, Qwen and Kimi get their reasoning_content back during a
  tool loop. See model providers.
• Model call options on every model component: maxRetries (429, 5xx and timeouts, with
  backoff), fallbackModels, an exact responseCache and coalesce for identical concurrent
  requests, all in process. Prompt caching: anthropic adds cache_control breakpoints by
  default and aws-bedrock adds Converse cachePoints with promptCaching=true;
  CamelAiCacheReadTokens and CamelAiCacheWriteTokens report cached input.
• Example examples/agents/mcp-shop: an online shop's back office as an MCP server (19
  tools, policies, prompts, approvals, a manager in the loop, a size question), with the requests
  that the field test ran and the guide "Ask Claude about your business"
  (docs/guides/mcp-shop-example.md).
• What a field test with Claude and the official MCP client found (scripts/mcp-fieldtest,
  40 real requests against an online shop's back office served by Cameleer):
  camel.server.mcp-resource-tool lets the model read resources through a tool;
  a tool route can refuse with CamelAiToolIsError=true and its own words; an approval
  form's Accept approves; the route of an approved call sees CamelAiToolApprovedBy; with an
  approvalEndpoint, calling again returns "still waiting" or the decision instead of a second
  request; date arithmetic (date - date, date ± n) in the embedded SQL engine.
• Keep-alive connection pools for the REST clients of the SaaS components and the cloud
  clients: model and API calls after the first skip the TCP and TLS handshakes.

Changed

• openai/llm and the other model components: parallelToolExecution now defaults to
  false and hallucinatedToolNameStrategy takes Camel's failExchange and repromptModel
  (the default; report and fail still work); maxAgenticTokens=0 means unlimited, as in
  Camel. The agent step's parallelToolCalls is unchanged.
• MCP server, as in Camel: camel.server.mcp-tags=* no longer exposes untagged items (the
  new pattern untagged does; --mcp and --mcp-stdio default to *,untagged); the server
  name defaults to the context's name; route exceptions reach clients as a generic message
  with an error id unless camel.server.mcp-expose-errors=true; the keep-alive interval is
  30 s and idle legacy sessions expire after 5 minutes. New properties
  camel.server.mcp-server-title, -server-description, -server-website-url and
  -server-icons.
• ai-tool: description defaults to the tool's name, as in Camel.
• ai-tool deduplication without a call id now includes the conversation (over MCP the
  session or io.cameleer/conversationId): retries are still caught, two conversations asking
  for the same thing no longer get each other's result.
• MCP: errors in a tool's route after an approval are sanitized like other route errors.
• A rejected or declined approval now tells the model that the call did not run and nothing was
  changed, and a decline in the client says the user declined it in the approval form (smaller
  models read "declined in the client" as the system refusing).

Install: cargo install cameleer-main, or `docker p...

Cameleer 0.4.0

Same Camel routes. 450x faster startup, up to 54x less memory, 1.7–8.7x the throughput.

We ran the same routes on Cameleer and on Apache Camel, both on the JVM and compiled natively with Quarkus. The routes covered in-memory routing, REST APIs, Kafka, PostgreSQL and batch jobs. Cameleer came out ahead in every scenario.

Full comparison: https://pmsudhi.github.io/cameleer/compare/apache-camel-vs-cameleer/

	Cameleer 0.4.0	Apache Camel 4.23 (JVM)	Apache Camel 4.22 (Quarkus native)
Startup	3 ms	1.1 s	30 ms
Memory, same route	8 MB	399 MB	113 MB
REST API with JSON	80.3k req/s	37.9k req/s	17.9k req/s
HTTP into PostgreSQL	11.0k req/s	4.8k req/s	3.6k req/s
HTTP into Kafka	17.8k req/s	10.1k req/s	9.3k req/s
Kafka stream processing	6.0k records/s	698 records/s	694 records/s

The method, every scenario and the raw data are in the benchmark report. You can reproduce the run with scripts/cloud-bench for about a dollar of cloud time.

Get it

docker pull pmsudhi/cameleer:0.4.0      # also ghcr.io/pmsudhi/cameleer:0.4.0
cargo install cameleer-main             # the cameleer CLI

Crates: cameleer-* 0.4.0 on crates.io.

New

• AWS Lambda custom runtime. cameleer run serves provided.al2023 invocations itself, with no adapter or layer. API Gateway and function URL events go to your platform-http routes in process; other events go to direct:lambda. Package a function with scripts/package-lambda.sh. See AWS Lambda.
• Build features. Build only the component families your routes use, for example --features cloud,jq or docker build --build-arg FEATURES=cloud,jq .. The core build is 5.8 MB.
  • Every component page names its feature.
  • A missing feature fails at startup with the feature to add.
  • See the build features guide.
• Fewer threads at rest.
  • Thread pools start workers on demand, so an idle HTTP route holds 2 threads instead of 34.
  • Timer routes that share a name share one thread, as in Camel.
  • XQuery and XSLT run on the caller's thread and are 10–35x faster per evaluation.
• Startup recorder: camel.main.startupRecorder=logging logs each startup step and its duration.

Fixed

These were found by running real workloads for the benchmark:

• HTTP server: more than 32 concurrent keep-alive clients reconnected on every request. It now has 200 workers, started on demand, and REST throughput roughly doubled.
• Kafka producer: concurrent sends were sent one record at a time. They are now batched into one request per broker, as Kafka's own producer does.
• PostgreSQL pool: poolSize now caps open connections, like HikariCP. A caller waits up to poolTimeout for a free one.
• TLS: a server's certificate rejection could be lost to a TCP reset on Windows.

Upgrading from 0.3

• A feature list now replaces the default for the optional parts too. The template engines, jq, the core XPath subset, http2 and cameleer validate are now features. If you built with a list such as --features cloud, add the parts you use, for example --features cloud,jq,validate.
• The default build, the Docker image and Rust programs that depend on cameleer-core or cameleer-http are unchanged.

Comparisons

• Apache Camel vs Cameleer
• Apache Camel alternatives
• AI agent tool calls: direct vs through Cameleer

Full changelog: CHANGELOG.md

Contributing

Found a problem? Open an issue, fork, fix, add a test, and open a pull request. Coding agents are welcome to do the same.

---

Cameleer is an independent project. It is not affiliated with or endorsed by the Apache Software Foundation. Apache, Apache Camel and Camel are trademarks of the ASF.

Cameleer 0.3.0

Validate routes before you run them, and write them with a complete YAML DSL reference. Built for people and for the coding agents that generate routes.

Docs: https://pmsudhi.github.io/cameleer/docs/

New: cameleer validate

Checks YAML and XML route files without starting a route or connecting to anything:

cameleer validate routes/ --format json
docker run --rm -v "$PWD:/routes:ro" pmsudhi/cameleer:0.3.0 validate /routes

code	severity	catches
yaml-syntax, xml-syntax	error	malformed files, with line and column
dsl-structure	error	unknown or misplaced steps and keys, missing required keys, with "did you mean setHeader?" hints
endpoint	error	unknown schemes and misspelled endpoint options, checked against the real components the same way Apache Camel does
expression	error	Simple, JSONPath, jq, XPath and other expressions that don't compile
unresolved-placeholder	warning	{{...}} with no value and no default
dangling-endpoint	warning	to: direct:x with nothing consuming direct:x
duplicate-route-id	error	two routes with one id

Text or JSON output, exit code 0 (valid), 1 (errors, or warnings with --strict), 2 (usage). Use it in CI, in a pre-commit hook, and in a coding agent's write-validate-fix loop. Every documentation example and every file in examples/ passes it in the test suite.

New: cameleer schema

Prints a JSON Schema (draft 2020-12) of the YAML DSL, generated from the same tables the validator and the loader use, for completion and inline errors in VS Code and JetBrains IDEs: cameleer schema > cameleer.schema.json.

New documentation

• YAML DSL reference: every top-level element, endpoint form, expression form and step, with tested examples.
• YAML for coding agents: a checklist, starting skeletons, the rules that prevent the usual mistakes, and the validate loop with a worked example.
• Validate guide, including CI and pre-commit setups.
• AGENTS.md for coding agents working on the repository, and the docs as an MCP server: https://gitmcp.io/pmsudhi/cameleer.

Install

docker pull pmsudhi/cameleer:0.3.0      # also ghcr.io/pmsudhi/cameleer:0.3.0
cargo install cameleer-main             # the cameleer CLI

Crates: cameleer-* 0.3.0 on crates.io.

Contributing

Starter issues are open (good first issue). Found a problem? Open an issue, fork, fix, add a test, open a pull request. Coding agents are welcome to do the same.

---

Cameleer is an independent project. It is not affiliated with or endorsed by the Apache Software Foundation. Apache, Apache Camel and Camel are trademarks of the ASF.

Cameleer 0.2.1

A hardening release: a production-ready container image, a fix for suspending polling routes, complete documentation, and the CLI under its own name.

Website and docs: https://pmsudhi.github.io/cameleer/docs/

Get it

docker run --rm -p 8080:8080 -v "$PWD:/routes:ro" pmsudhi/cameleer:0.2.1 run /routes/hello-api.camel.yaml
cargo install cameleer-main        # the `cameleer` CLI

Images: Docker Hub pmsudhi/cameleer and ghcr.io/pmsudhi/cameleer (linux/amd64, linux/arm64). Crates: cameleer-* 0.2.1.

Changed

• The CLI is cameleer only. The camel binary is gone: camel is Apache Camel's own CLI name. The subcommands are unchanged and follow Camel JBang (cameleer run, cameleer ps, cameleer stop, ...). Replace camel with cameleer in scripts.

Fixed

• Suspending a polling route now waits for a poll in progress, as Apache Camel does. Before, a file (or FTP, mail, S3, ...) consumer could still pick up a message just after suspend returned. A route that suspends itself from inside its own poll does not deadlock.
• mongodb-gridfs no longer skips a file stored in the same millisecond as the previous one.
• Property values like camel.server.port={{env:PORT:8080}} now resolve (Cloud Run, Knative).
• cameleer get health exits with status 1 when the integration is DOWN, so it works as a container health check.
• Status files for cameleer ps/stop/log are best-effort: a read-only filesystem no longer stops the integration. CAMEL_LOCAL_STATUS=false turns them off.

Container image

• glibc binary on distroless/cc (static musl measured 3-17% slower), built with thin LTO.
• Runs as non-root, works with --read-only and any --user, writes nothing, stops cleanly on SIGTERM.
• Every platform is built and smoke-tested before it is pushed. Each push carries an SBOM, max-mode build provenance and a GitHub attestation: gh attestation verify oci://ghcr.io/pmsudhi/cameleer:0.2.1 --owner pmsudhi.
• Deployment guide: Docker, Compose, Kubernetes, Cloud Run.

Documentation

• A page for every component (164), language (26) and data format (29), plus guides: getting started, concepts, every EIP, error handling, an agent cookbook, an edge cookbook, migrating from Apache Camel, cloud credentials, AI components, FAQ.
• More than 400 examples, every one tested: each endpoint URI is checked against the real component, and most examples run end to end against embedded servers and mocks.
• Connect your coding agent: the docs as an MCP server (https://gitmcp.io/pmsudhi/cameleer), plus Context7 and DeepWiki.
• Read the Docs configuration, llms.txt, llms-full.txt, sitemap and structured data.

Unchanged

The engine, the components and the performance: 10 ms startup, about 10 MB of memory, 2.5-8x Apache Camel's throughput on Java 21 (all six benchmarks).

Contributing

14 starter issues are open, seven labelled good first issue. Found a problem? Open an issue, fork, fix, add a test, open a pull request. Coding agents are welcome to do the same.

---

Cameleer is an independent project. It is not affiliated with or endorsed by the Apache Software Foundation. Apache, Apache Camel and Camel are trademarks of the ASF.

Cameleer 0.2.0

rust-camel is now Cameleer. Same engine, new name, and now packaged as a container image and on crates.io.

If you know Apache Camel, you already know Cameleer: the same routes, EIPs, endpoint URIs, Simple expressions and YAML DSL, rebuilt in Rust as one static binary.

Website: https://pmsudhi.github.io/cameleer/

Get it

Docker (linux/amd64, linux/arm64), on Docker Hub and as ghcr.io/pmsudhi/cameleer:

docker run --rm -p 8080:8080 -v "$PWD:/routes:ro" pmsudhi/cameleer:0.2.0 run /routes/hello-api.camel.yaml

CLI from crates.io. It installs as cameleer, and as camel for Camel JBang habits:

cargo install cameleer-main

Rust crates: cameleer-core (engine, EIPs, Rust DSL) plus one crate per area, such as cameleer-http, cameleer-kafka-mqtt, cameleer-cloud and cameleer-saas. cameleer-main bundles them all.

[dependencies]
cameleer-core = "0.2"
cameleer-http = "0.2"

What's new since 0.1.0

• New name. Another active project uses the name rust-camel and owns most camel-* names on crates.io. Crates are now cameleer-* and module paths are cameleer_*. The repository moved to pmsudhi/cameleer, and GitHub redirects the old URL.

• Container image pmsudhi/cameleer on Docker Hub, also ghcr.io/pmsudhi/cameleer. It's built from a pinned, digest-verified toolchain by cross-compiling to static musl, so arm64 needs no emulation.

• Published on crates.io: 19 crates, with no third-party dependencies: https://crates.io/crates/cameleer-main

• Tested real-world examples in examples/:

  • REST APIs
  • AI ticket triage (Kafka plus an LLM)
  • alerts to Slack
  • files to S3
  • two Rust programs

  Each one runs end to end in the test suite against an embedded Kafka broker and mock S3, Slack and OpenAI servers.

• Fixes:

  • The mongodb-gridfs consumer skipped a file stored in the same millisecond as the previous one.
  • The GCP calendar mock lost events created in the same millisecond as a sync token.
  • camel-bench didn't build on Linux.
  • The gpg interop tests failed with Git for Windows' gpg.

• Repository: Apache-2.0 LICENSE and NOTICE, contributing and security guides, CI on Linux and Windows, citation metadata, llms.txt, and a project website.

Unchanged from 0.1.0

The engine, about 230 components, the DSLs and the performance are unchanged. The benchmarks still apply: 10 ms startup, about 10 MB of memory, and 2.5–8x Apache Camel's throughput on Java 21.

---

Cameleer is an independent project. It is not affiliated with or endorsed by the Apache Software Foundation. Apache, Apache Camel and Camel are trademarks of the ASF.

rust-camel 0.1.0

The first public release of rust-camel: Apache Camel's integration model, rewritten in Rust on the standard library alone.

If you know Camel, you already know rust-camel. It uses the same endpoint URIs, Enterprise Integration Patterns, Simple expressions, YAML routes, headers and error handling.

Website: https://pmsudhi.github.io/Rust-camel/

What's in 0.1.0

• The routing engine and all of Camel's EIPs: content-based router, splitter, aggregator, recipient list, wire tap, circuit breaker, saga, resequencer and the rest.
• About 230 components, languages and data formats. Each has its options, and the full list is in docs/FEATURES.md.
• DSLs: Rust, YAML and XML, plus the REST DSL, Kamelets and route templates.
• Operations: management, health checks, and a camel CLI in the style of Camel JBang.
• AI integrations:
  • OpenAI-compatible chat and embeddings
  • AWS Bedrock
  • Azure OpenAI
  • Google Vertex AI
• No third-party crates. These are all written from scratch:
  • TLS 1.3/1.2, X.509, SSH-2/SFTP
  • HTTP/1.1, HTTP/2, gRPC
  • AMQP 0-9-1 and 1.0, MQTT, STOMP, the Kafka wire protocol
  • PostgreSQL, Redis, MongoDB and Cassandra wire protocols
  • YAML, JSON, XML/XPath/XSLT

Performance against Apache Camel 4.23 on Java 21

Same routes, same machine (Ryzen 5 5600X, Windows 11). Full method and tables are in docs/BENCHMARKS.md.

	rust-camel vs Camel
Startup	10 ms vs 751 ms (77x faster)
Peak memory	25–46x less
direct route throughput	4.27x
seda InOnly / InOut	4.18x / 8.37x
content-based router	3.48x
split + aggregate	3.18x
HTTP	2.45x (the load generator shares the CPU, so this is capped at about 3.6x on this machine)

Verification

• Hermetic tests: 2,300+, with zero build warnings, on Linux and Windows. Embedded servers stand in for the network.
• Real servers:
  • PostgreSQL 16, Redis 7, Mosquitto
  • RabbitMQ, ActiveMQ 5.17
  • vsftpd, Postfix + Dovecot
  • nginx, OpenSSL, JDK JSSE
• Official clients:
  • librdkafka/kcat, pymongo, the DataStax Cassandra driver
  • elasticsearch-py, redis-py
  • boto3, the Azure SDK, gcloud
  • grpcio, Go crypto/tls and net/http
• Simulators: moto, Azurite, fake-gcs-server, pstest, FerretDB and kfake.
• Bugs: about 30 interoperability bugs were found this way and fixed, each with a regression test. They're listed in docs/INTEROP.md.

Known limits

• Pre-1.0. Public APIs may still change.
• Not packaged yet: an MCP server, a native AWS Lambda runtime, and vector store components. Patterns for building them on the engine are in docs/ROADMAP.md.
• No security audit yet. The from-scratch crypto and protocol code hasn't been independently audited (planned).
• No real cloud accounts yet. The cloud components are verified against emulators, not live AWS, Azure or GCP accounts.

---

rust-camel is an independent project. It is not affiliated with or endorsed by the Apache Software Foundation. Apache, Apache Camel and Camel are trademarks of the ASF.