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, Pipebase resolves params in this order (later wins):

1. Global defaults (set in the parameters list)
2. Runtime overrides (per-runtime in the registry)
3. Flow-level overrides (the flow’s params.json)

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