Publishing

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.

Setup Trigger

If the workflow has a route flagged as its Setup Trigger, that route fires automatically — once, fire-and-forget — every time a published version is deployed to an environment (the create and the update of that environment's live instance). It runs in the environment being deployed to, with origin: setup (route auth skipped, private routes allowed, shown in the Executions list). Its request body carries the workflow's own callable URLs for that environment — {{trigger.body.url}}, {{trigger.body.hooks}}, {{trigger.body.environmentId}} — so a setup step can, for example, register those endpoints as webhooks with a third-party service. A failed setup run is logged but never blocks the deploy. The flag is read from the published snapshot, so toggling it only takes effect after the next 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.