younifyd
Menu

Concepts

Environments

A named, store-scoped deployment target like Production or Staging — how a request selects one, and why each gets its own independent live instance of a published workflow.

On this page

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 (e.g. via a Proxy or Workflow-invoking step) inherits the same environment as the top-level request, 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.

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.