CameleerCameleer / Cameleering
cameleer.ing
What is cameleering?
Cameleering is running Apache Camel integration routes on Cameleer: the same Enterprise Integration Patterns, endpoint URIs, Simple expressions and YAML DSL, executed by one native Rust binary instead of the Java virtual machine. Routes start in milliseconds and run in megabytes, so Camel-style integration goes where a JVM does not fit: edge devices, serverless functions, and the action layer behind AI agents.
Where cameleering fits
Anywhere an integration has to start fast, stay small or act reliably, and a JVM is the part that does not fit.
At the edge
- MQTT 3.1.1 and 5.0, syslog and HL7 v2 over MLLP on a gateway, with a
linux/arm64image. - Filter and aggregate on site, buffer to disk when the uplink is down, forward to Kafka or HTTP later.
- MQTT edge gateways · HL7 over MLLP
In serverless functions
- The binary is its own AWS Lambda runtime (
provided.al2023); the same route runs on Cloud Run, Knative and Azure Container Apps. - A 3 ms start leaves scale to zero with no practical cold-start cost from Cameleer itself.
- Serverless on AWS Lambda and Cloud Run
Behind AI agents
- Routes become MCP tools with one flag (
cameleer run tools.camel.yaml --mcp). - Every call is validated against a schema, runs once, waits for approval when it is risky, cancels on timeout, rolls back and lands in a hash-chained audit log.
- Routes as MCP tools · Tool calls direct vs through Cameleer
Next to the services you already run
- Kafka, PostgreSQL, S3, SFTP and REST APIs, as a sidecar or one small container per integration.
- Tens of megabytes per integration instead of hundreds, so many fit on one node.
- File and SFTP pipelines · All use cases
Cameleering vs Apache Camel on the JVM
| same routes | Cameleer | Apache Camel (JVM) | Apache Camel (Quarkus native) |
|---|---|---|---|
| time to a started context | 2.5 ms | 1106 ms | 30 ms |
| memory at startup | 8 MB | 114 MB | 69 MB |
| peak memory, direct route | 7 MB | 399 MB | 113 MB |
| request-reply over an in-memory queue | 719,433 msg/s | 117,442 msg/s | 72,113 msg/s |
| REST API with JSON | 80,367 req/s | 37,814 req/s | 17,860 req/s |
| what you deploy | one native binary | a JVM plus JARs | one native image |
Apache Camel 4.23.0 on Java 21 and Camel Quarkus 3.40.0 native against Cameleer 0.4.0, on three identical cloud machines with 4 dedicated vCPUs each. Every scenario, the method and the raw data: Apache Camel vs Cameleer.
What changes underneath, and what stays
Changes
- No virtual machine. Rust compiles ahead of time; there is no JIT warm-up and no garbage collector, so routing never pauses for GC and memory is freed as soon as it is unused.
- No dependency tree. TLS, HTTP/2, gRPC, AMQP, MQTT, the Kafka and PostgreSQL protocols, XML and JSON are written on the Rust standard library alone.
- Threads that start on demand. Pools grow when work arrives and shrink when it stops: an idle HTTP route runs on a handful of threads.
- Only what the routes use. Cargo build features cut the binary to 5.9 MB with
core.
Stays the same
- Endpoint URIs and their options, the Enterprise Integration Patterns, Simple, JSONPath, XPath and jq.
- The YAML and XML DSLs, the REST DSL, Kamelets and route templates;
Camel*headers and exchange properties. onException, redelivery and the dead letter channel.- The Camel JBang workflow:
cameleer run,ps,stop.
About 230 components, languages and data formats ship today, including every Apache Camel AWS, Azure and Google Cloud component; Apache Camel has 300+ components, so check the component index for the long tail. Java beans and custom Java components are written in Rust instead.
Common questions
What is cameleering?
Cameleering is running Apache Camel integration routes on Cameleer: the same Enterprise Integration Patterns, endpoint URIs, Simple expressions and YAML DSL, executed by one native Rust binary instead of the Java virtual machine. Routes start in about 3 ms and run in megabytes, so Camel-style integration fits on edge devices, in serverless functions and behind AI agents.
Where does the word come from?
A cameleer is a person who drives camels. Cameleer drives Apache Camel's routes; cameleering is the act of doing so. The project's short domain is cameleer.ing.
Do I have to rewrite my Camel routes?
No for YAML and XML routes: they run unchanged with cameleer run. Routes written in the Java DSL are rewritten in the Rust DSL, which uses the same method names in snake_case. Java beans, processors and custom components are not supported; they are written in Rust. See migrating from Apache Camel.
Is cameleering an Apache Software Foundation project?
No. Cameleer is an independent open-source project under the Apache License 2.0. It follows Apache Camel's names and semantics but contains no Camel source code and is not affiliated with or endorsed by the ASF.
Which edge protocols does it speak?
MQTT 3.1.1 and 5.0, syslog, HL7 v2 over MLLP, HTTP, WebSocket, TCP and UDP, Kafka and AMQP, with a linux/arm64 image for 64-bit gateways. Modbus and OPC UA are not supported.
How is Cameleer faster than Apache Camel on the JVM?
There is no virtual machine to start, no JIT warm-up and no garbage collector; the binary is compiled ahead of time and memory is freed deterministically. On three identical cloud machines with the same routes, Cameleer started in 2.5 ms against 1106 ms, peaked at 7 MB against 399 MB on the same route, and handled 1.7 to 8.7 times the throughput of Apache Camel 4.23 on Java 21.
Start cameleering
Save a Camel YAML route as hello-api.camel.yaml (or take the example) and run it:
docker run --rm -p 8080:8080 -v "$PWD:/routes:ro" pmsudhi/cameleer run /routes/hello-api.camel.yaml curl localhost:8080/orders/42