Runtimes

A runtime is a Camel-runtime container the designer can deploy flows to. Each runtime is a single Docker container exposing a management API at /_api/*.

Topology

The expected pattern: one runtime per environment.

Environment	Hostname	Default URL
prod	runtime.<root>	the root, no env prefix
stag	stag.<root> (or wherever you point it)	second-tier
test	test.<root>	integration
dev	dev.<root>	bottom of the chain

You can have any number of runtimes — Pipebase doesn’t cap them. The SPA’s Environments page lists them all with health pings.

Default vs additional

The first runtime gets isDefault: true automatically. Flows deployed without an explicit ?runtimeId= query param land there.

Add additional runtimes via:

• Connect existing — point at an already-running container at any URL with any deploy token. Ideal for connecting an external server or a separate cluster.
• Provision new — designer talks to the local Docker daemon and spins up a fresh pipebase-runtime container with the right Traefik labels. Requires PIPEBASE_RUNTIME_ROOT_DOMAIN set.

Per-runtime parameter overrides

Each runtime can override {{paramName}} placeholder values. At deploy time, parameters resolve in this order (later wins):

1. Global defaults — set in the parameters list at org level.
2. Runtime overrides — per-runtime overrides for global parameters.
3. Flow cutover values — per-flow, per-runtime values from the Cutover matrix.

A {{paramName}} in a flow YAML that resolves to no value in any layer fails deploy with a “missing parameter” error listing the keys.

So you can have one YAML where {{salesforce-host}} resolves to acme.my.salesforce.com in prod and acme--dev.sandbox.my.salesforce.com in dev, without touching the flow.

Related

• Transport routes — the chain that connects runtimes for promotion
• Flows — what gets deployed onto runtimes
• Cutover — per-flow per-runtime parameter matrix with promote and audit history