Configuration: properties, profiles and environment variables

Cameleer reads its configuration the way Camel Main and Spring Boot do: application.properties or application.yaml, profile files such as application-prod.properties, CAMEL_* environment variables, and --prop on the command line, with later sources winning. Every key is a placeholder routes can use ({{orders.target}}), and camel.main.*, camel.server.*, camel.ssl.*, camel.datasource.* and camel.component.* keys configure the runtime without code.

Applies to: the cameleer CLI, the Docker image and cameleer_main::Main in Rust · Apache Camel: Camel Main configuration

Where configuration comes from

Sources are merged in this order; a later source overrides an earlier one:

Keys match without regard to case, dashes and underscores: camel.main.durationMaxSeconds, camel.main.duration-max-seconds and CAMEL_MAIN_DURATION_MAX_SECONDS are the same key. The Spring Boot and Quarkus spellings work too: camel.springboot.* and quarkus.camel.* are read as camel.main.*, and server.port or quarkus.http.port as camel.server.port when that is not set.

In the Docker image the working directory is /routes, so an application.properties in the mounted folder is read:

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

application.properties and application.yaml

Either format works; YAML maps are flattened to dotted keys, lists to key[0] (and a list of plain values also to one comma-separated value):

camel.main.name = orders
camel.server.port = 8080
orders.batch-size = 100

camel:
  main:
    name: orders
  server:
    port: 8080
orders:
  batch-size: 100

Profiles

A profile switches settings per environment. Activate one with cameleer run --profile prod, --dev (profile dev), the property camel.main.profile (also spring.profiles.active, quarkus.profile), the environment variable CAMEL_MAIN_PROFILE (also SPRING_PROFILES_ACTIVE, QUARKUS_PROFILE), or Main::set_profile in Rust. Several profiles are separated by commas. An active profile adds:

• application-<profile>.properties (or .yaml, .yml) from the same folder;
• Quarkus-style entries %<profile>.key=value in any file;
• YAML documents with spring.config.activate.on-profile: <profile> (or spring.profiles).

The log says The following profiles are active: prod. A worked example is below.

Environment variables

Variables that start with CAMEL_ become properties and override the files:

The rule: drop CAMEL_, lowercase, the first part after camel. becomes a segment, and the rest is joined in camelCase; for CAMEL_COMPONENT_* the longest known component scheme is matched first. Because keys match loosely, camel.server.mcpRequestStateKey and camel.server.mcp-request-state-key are the same.

Any value can also read an environment variable directly with a placeholder, {{env:NAME}} or {{env:NAME:default}}, which is the usual way to pass secrets:

camel.server.port = {{env:PORT:8080}}
camel.datasource.url = {{env:DB_URL}}

Other variables Cameleer reads:

Placeholders

Every property can be used in routes and in other properties:

Placeholders inside camel.main.* and camel.server.* values are resolved before the runtime reads them, so camel.server.port={{env:PORT:8080}} works on Cloud Run, Knative and anywhere else that passes the port in PORT. cameleer validate reports a placeholder no source defines as unresolved-placeholder.

The keys

camel.main.*: the runtime

camel.server.*: the shared HTTP server, health, metrics and consoles

platform-http and REST routes, the management endpoints and the MCP server share one HTTP server.

cameleer run --console turns on camel.server.enabled, health, metrics and the dev console in one flag. With camel.server.sslEnabled=true the management endpoints, /q/attestation and the MCP server are HTTPS on the same port as the routes.

camel.management.*: a separate management port

See Observability.

camel.ssl.*: global TLS

Endpoints with useGlobalSslContextParameters=true, and components that fall back to the global parameters, use these. They apply only with camel.ssl.enabled=true.

camel.datasource.*: databases for sql, jdbc and sql-stored

# one data source, bound as "dataSource" (or the name in camel.datasource.name)
camel.datasource.url = jdbc:postgresql://db:5432/shop
camel.datasource.username = app
camel.datasource.password = {{env:DB_PASSWORD}}

# more, each bound under its own name
camel.datasource.reports.url = jdbc:postgresql://reports:5432/bi

Routes refer to them as sql:select ...?dataSource=#reports. See sql.

camel.component.<scheme>.<option>: defaults for every endpoint of a component

camel.component.kafka.brokers = {{env:KAFKA_BROKERS:localhost:9092}}
camel.component.seda.queueSize = 10000

An option on the endpoint URI still wins over the component default.

camel.beans.*: beans

camel.beans.<name>=#class:<type> plus camel.beans.<name>.<property>=value create a bean through a factory registered for that type in Rust (cameleer_yaml::register_bean_factory). The cameleer binary registers no factories, so with the CLI and the Docker image these entries are logged and skipped; see what works without Rust.

What works without Rust

Everything in a route URI, and everything on this page except beans, works from the CLI and the Docker image. Some options take a reference to an object in the registry (#name):

A worked example

One route, three environments. The route sends orders to a target chosen by configuration:

- route:
    id: orders
    from:
      uri: direct:order
      steps:
        - to: "{{orders.target}}"

camel.main.name = orders
orders.target = log:orders?level=INFO
%dev.orders.target = log:orders?level=DEBUG

camel.server.port = {{env:PORT:9090}}
orders.target = log:orders?level=WARN

The test configuration_guide_worked_example (crates/cameleer-main/tests/docs_reference.rs) writes these files from this page and checks every row of the table.

In Rust

cameleer_main::Main reads the same sources:

let mut main = cameleer_main::new_main();
main.load_application_config(".")?;          // application.properties / .yaml
main.set_profile("prod");                    // or CAMEL_MAIN_PROFILE
main.set_property("camel.server.port", "9090"); // like --prop
main.add_route_file("orders.camel.yaml");
main.run()?;

Common questions

How do I use different settings for development and production?

Put the shared settings in application.properties, the production ones in application-prod.properties (or %prod.key=value lines), and start with --profile prod or CAMEL_MAIN_PROFILE=prod. See Profiles.

How do I pass a secret without putting it in a file?

Use {{env:NAME}} in the property or route (camel.datasource.password={{env:DB_PASSWORD}}), or a vault function such as {{aws:orders/db-password}} (cloud credentials).

How do I change the port?

--port 9090, camel.server.port=9090, CAMEL_SERVER_PORT=9090, or camel.server.port={{env:PORT:8080}} to follow the platform's PORT.

Why is my application.properties ignored?

cameleer run reads it from the current directory; run from that folder, or pass --properties path/to/application.properties (which then replaces the files of the current directory). In Docker, mount the folder at /routes, the image's working directory.

Why does a camel.ssl.* setting have no effect?

Set camel.ssl.enabled=true; without it the global TLS parameters are ignored.

Which keys does a component read from configuration?

Any endpoint option, as camel.component.<scheme>.<option>; the options are listed on each component page.

Related

• CLI reference, Deployment, Cloud credentials
• MCP server configuration
• TLS and security for every camel.ssl.* and camel.server.ssl.* key, observability for the management server

Found a problem?

If something on this page doesn't match what Cameleer does, please open an issue, or fork the repository, fix it, add a test, run cargo test --workspace and open a pull request.