Environments

What an environment is

An environment is a named, store-scoped deployment target — e.g. "Production" and "Staging" — that a published workflow is deployed to before it serves real traffic. Exactly one environment per store is the default; if a store has none yet, deploying a workflow for the first time auto-creates one named "Production" as the default.

Selecting an environment

A request targets a specific environment by sending its id in the X-REQUEST-ENVIRONMENT-ID header. Omit the header and the request uses the store's default environment instead. This selection carries through the whole request chain — a nested workflow call (via an Invoke Workflow, Invoke Route, or Proxy step) inherits the same environment as the top-level request by default, so a multi-workflow call graph stays pinned to one environment throughout.

If a workflow hasn't been deployed to the environment a request names, that request fails outright rather than silently falling back to another environment's configuration or credentials. This applies to nested calls too: an invoked workflow that isn't published to the caller's environment fails — unless the calling step turns on Exclude Environment, which runs the target against its own default published instance instead of the caller's environment.

Reading the environment id in a workflow

The resolved environment id is available to any workflow's steps as {{trigger.environmentId}} — useful for building environment-scoped cache keys or branching on which environment a run belongs to. A nested workflow receives the originating environment id there (the one the top-level request selected), unchanged by Exclude Environment or by any intermediate level in the call chain.

One live instance per environment

Each environment gets its own independent live instance per workflow — deploying a published version to an environment creates or updates that environment's instance specifically. This means:

• Staging and Production can run different published versions of the same workflow at once.
• The same version can hold different variable values per environment — separate API keys, endpoints, or feature flags for staging vs. production, resolved through each environment's own variable values.

A route's public/private type and auth method come from whichever published version an environment is running, so they're identical across every environment running that version — only the resolved secret value (via that environment's own variable configuration) can differ per environment.

Managing environments

Environments can be created, renamed, and deleted independently of publishing. The default environment can't be deleted — set another one as default first — and an environment still referenced by a live workflow instance can't be deleted until that instance is removed.