Deployments & environments

Promote flows from draft to production through versioned, reversible releases.

Environments

Each project has separate environments, typically Development, Staging and Production. An environment holds its own provider bindings, so the same flow can run against a test gateway in staging and a live one in production.

Environment variables

Each environment holds its own variables — key/value config such as auth tokens and API keys. Flows reference them in API-call nodes as {{env.NAME}}, so the same flow can authenticate against a sandbox in Development and a live service in Production without edits.

Manage them per environment on the Environments page. Values marked as secret are encrypted at rest and masked in the dashboard, with a reveal toggle for authorized members. Names are UPPER_SNAKE_CASE (e.g. API_TOKEN).

Secrets stay out of logs

Environment variables are injected only when an API node runs; they are never written into session state, the event log or webhooks.

Versioning & the pipeline

Publishing a flow creates an immutable version. Releases move through a pipeline:

  1. 01Draft
  2. 02Test
  3. 03Review
  4. 04Publish

Rollbacks

Because versions are immutable, rolling back is just re-pointing an environment at a previous version, with no rebuild required.

Callback tokens

Binding a deployment to a provider environment mints an opaque callback token used in the webhook URL (see Providers & webhooks). Rotating a binding rotates the token without touching the flow.