Publishing & versions

The canvas always holds the draft. Production — webhooks, schedules, API-triggered runs — always executes the latest published version's snapshot. Saving an edit to a live workflow changes nothing in production until you publish it.

What publish does

1. Validates — the same flows.ValidateDefinition the API's /validate endpoint runs: structure, piece and action references against the piece catalog, required config present (with displayConditions evaluated, so a field that doesn't apply is never demanded), condition operators, step references, trigger config (cron syntax, timezones, watched workflows). Refusals name the fault and the admissible set.
2. Snapshots the draft as an immutable version (skipped when byte-identical to the last one — republishing without changes mints nothing).
3. Arms the trigger — mints the webhook URL, registers the schedule, subscribes the watcher.

Two green lights that then fail in production is the failure class this gate exists to prevent: what /validate accepts and what publish accepts are one function, so they cannot disagree.

Version history

Every version records who published it and a server-computed change summary ("Added Log it · Edited Fetch customers"). The panel states plainly which version is live and whether the canvas has unpublished changes.

• Restore copies an old version into the draft — nothing goes live until you publish again.
• Runs record which version they executed, so the run view always renders the graph that actually ran.

Unpublish

Takes the workflow offline: the webhook 404s, schedules stop. The draft and the version history are untouched.

Concurrent editing

Saves are guarded by an optimistic revision — two people (or a person and Keel) can't silently clobber each other; the loser gets an honest conflict. An advisory editing lock with a hand-over handshake keeps two builders from working the same canvas blind, and all writes to one flow serialize across the fleet.