Menu
Concepts
Publishing
What publishing a workflow actually does — a versioned, immutable snapshot of the draft — and why a published version doesn't serve traffic until it's deployed to an environment.
On this page
What publishing does
Publishing a workflow snapshots its current draft — every route, step, variable definition, policy reference, JWT config, and rate limit setting — into an immutable, versioned published workflow record. The draft keeps changing as you keep editing it; the published version is frozen at whatever the draft looked like the moment you published.
Each publish gets the next version number for that workflow (v1, v2, v3, ...) plus a set of release notes (AI-generated, or a plain summary if you skip that).
Publishing alone doesn't serve traffic
A published version only starts serving real requests once it's deployed to an environment — a separate action that creates or updates that environment's live instance, pointing it at a specific published version. A workflow can be published many times without ever going live, and an environment can stay on an older published version even after newer ones exist — nothing changes for that environment until you deploy the new version to it.
What a live instance snapshots
Deploying a published version to an environment fixes that environment's routes and steps to the published version's immutable snapshot. Two things are instead refreshed from the workflow's current settings at deploy time:
- Variable values — supplied per environment when you deploy, not copied from the workflow's variable defaults.
- Policies and JWT config — reloaded from the draft workflow's current policies/JWT settings every time a live instance is created or updated, so fixing an auth policy and redeploying the same published version to an environment picks up the fix without a new publish.
Draft testing vs. real traffic
These are different execution paths:
- Test executions (a route's Tests tab) run directly against the mutable draft workflow, using each variable's default value, and are never rate-limited.
- Real traffic resolves the request's environment to that environment's live instance, which pins execution to one specific published version and applies that environment's variable values, policies, JWT config, and rate limit.
No draining or rollback
Deploying a new published version to an environment overwrites that environment's live instance immediately — there's no draining period for in-flight requests, and no unpublish action. Rolling back to an earlier published version only restores it as the draft; it still needs to be published and redeployed before it takes effect on any environment.