| Variable | Description |
|---|
ROOT_DOMAIN | The domain Pipebase serves on. e.g. pipebase.example.com. Sub-domains derived from this unless overridden. |
LETSENCRYPT_EMAIL | Contact email for Let’s Encrypt cert notifications. Use a real inbox. |
PIPEBASE_DEPLOY_TOKEN | 32-byte hex bearer token between designer ↔ runtime /_api/*. Generate fresh per install: openssl rand -hex 32. |
Defaults follow the <service>.<root> pattern.
| Variable | Default | Description |
|---|
PIPEBASE_JWT_SECRET | unset (opt-in) | Opt-in. Off in both shipped compose files: commented lines on pipebase-designer + pipebase-runtime in the standalone compose, and never on the Coolify path, where a row on the Environment Variables tab reaches every container. Enabling it puts the designer token-signing key in the runtime env, readable by any deployed flow. HMAC-SHA256 signing key for OAuth-issued JWTs. Designer + runtime must see the same value. Setting it also pins the key: force-logout-all then rotates browser sessions only, leaving OAuth tokens valid until they expire, so runtimes keep accepting them. To retire a token early on a pinned install, delete its OAuth client — that retires every token the client issued, at once (designer 0.7.16+; before that the gate checked only the signature and a deleted client’s token kept working). Changing this value on the designer and every runtime and restarting them retires everything at once and is the bigger hammer. Note that the rotated session key lives in memory: a restart loads this value again, so signed-out sessions that have not expired start working again. Leave the variable unset (the shipped compose files do) and force-logout-all invalidates sessions and OAuth tokens together, durably. |
DESIGNER_HOST | designer.${ROOT_DOMAIN} | Hostname for the designer SPA + REST API |
RUNTIME_HOST | runtime.${ROOT_DOMAIN} | Hostname for the runtime’s public HTTP triggers + management API |
DOCS_HOST | docs.designer.${ROOT_DOMAIN} | Hostname for this docs site |
| Variable | Default | Description |
|---|
PIPEBASE_RUNTIME_URL | http://pipebase-runtime:8080 | Internal URL the designer dials. Docker DNS in compose. |
PIPEBASE_RUNTIME_PUBLIC_URL | https://${RUNTIME_HOST} | Public URL surfaced in the SPA so users see where their HTTP triggers are reachable. |
PIPEBASE_DATA_DIR | /data/flows | Disk root for designer flow storage inside the container |
PIPEBASE_WORKSPACE_ENFORCEMENT | report | What the designer’s workspace access layer does with a failed check: enforce refuses, report logs and counts but lets the request through (denies nothing), off skips the checks. Workspaces are not yet an isolation boundary in any mode. Both shipped compose files pass it to the designer with report as the default, so a value in the project’s .env takes effect; see docs/multi-tenancy.md in the repository for what to watch before enforce. |
PIPEBASE_RUNTIME_ROOT_DOMAIN | unset (opt-in) | Enables the managed-runtime feature: the designer provisions runtime containers at <env>.<this-value> through the Docker socket, which must also be mounted into the designer (root on the host). Off by default since 2026-09-30. |
PIPEBASE_RUNTIME_IMAGE | pipebase-runtime:0.6.0 | Image tag the managed-runtime feature uses for new containers; when that image is not on the host, the designer uses the last local pipebase-runtime tag in string order |
PIPEBASE_RUNTIME_NETWORK | coolify | Docker network for new runtime containers |
PIPEBASE_RUNTIME_CERT_RESOLVER | letsencrypt | Traefik cert resolver name for new runtimes |
PIPEBASE_RUNTIME_ENTRYPOINT | https | Traefik entrypoint for new runtimes |
PIPEBASE_DOCKER_SOCKET | /var/run/docker.sock | Path to the Docker socket inside the designer container |
| Variable | Default | Description |
|---|
PIPEBASE_PULSAR_URL | pulsar://pipebase-pulsar:6650 | Binary protocol endpoint |
PIPEBASE_PULSAR_ADMIN_URL | http://pipebase-pulsar:8080 | Admin REST API endpoint |
PIPEBASE_PULSAR_CLUSTER | pipebase-eu-west | The broker’s clusterName and the cluster the designer puts in allowedClusters when it provisions a tenant — one variable so they cannot drift |
PIPEBASE_PULSAR_PROTOCOLS | mqtt,amqp | Protocol handlers the broker loads: mqtt,amqp, or mqtt (AOP is AMQP 0-9-1, RabbitMQ dialect, not 1.0). Never kafka — the broker refuses to start |
PIPEBASE_PULSAR_TOKEN_AUTH | true | The broker refuses clients without a token it signed, on the admin API, the Pulsar binary port, MQTT (password = token) and AMQP (SASL mechanism token). It mints its own key and the designer’s and runtime’s tokens into volumes; mint one for an external client with docker exec pipebase-pulsar bin/pipebase-token.sh create <name>. What a token may do is decided by PIPEBASE_PULSAR_AUTHORIZATION (on by default): Pulsar and MQTT clients need a namespace grant; AMQP clients are not authorized. false restores the open broker and needs PIPEBASE_PULSAR_AUTHORIZATION=false as well — with authorization on and authentication off the broker refuses to start |
PIPEBASE_PULSAR_ADMIN_TOKEN_FILE | /run/pipebase/pulsar/token (set by the compose) | Designer: file holding its broker token. PIPEBASE_PULSAR_ADMIN_TOKEN passes it inline instead — avoid that under Coolify, where every variable reaches every container |
PIPEBASE_PULSAR_TOKEN_FILE | /run/pipebase/pulsar/token (set by the compose) | Runtime: file holding its broker token, used by pulsar: routes and the /_api/pulsar proxy. PIPEBASE_PULSAR_TOKEN passes it inline — readable by every deployed flow |
| Variable | Default | Description |
|---|
LOG_LEVEL | info | Pino log level: trace, debug, info, warn, error, fatal, silent |
The committed .env.example at the repo root is the authoritative
reference — this table mirrors it. If they diverge, the file wins;
write to hello@pipebase.dev.
