Versions and rollout

A flow's source lives in its draft — the copy the browser editor and the CLI both edit. Publishing freezes the draft as a numbered version. Deployments run versions, never the draft.

Publishing#

Publishing does two things: it snapshots the draft as version n, and it starts building that version's bundle in the background.

A version's build passes through PENDING → QUEUED → BUILDING → READY, and only READY can be dispatched. That is why publishing is a state to watch rather than an instant — for a few seconds the version exists but cannot run.

A build that fails ends FAILED and keeps the error on the version. That is a compile problem in your source, not a platform fault.

Which version a deployment runs#

Each deployment pins one version, and there are two ways to manage that:

The usual arrangement is auto-update on a staging deployment and pinned on production, so publishing is safe by default and promoting is an explicit act.

Rolling back#

Rolling back is repointing the deployment at an earlier version. The old version is still there, still bundled, still READY — nothing needs rebuilding.

Two things that sound like rollback and are not:

• Checking a version out seeds the draft from it — in the editor, or with konnecthub checkout <n>. Every deployment carries on serving whatever it was serving. This is for looking at, or editing from, old code.
• Publishing after a checkout produces a new version number holding the old code. Version numbers are max + 1 and carry no ancestry, so after rolling back to v1 your next draft is v4. The platform records what it was forked from; the number does not tell you.

Moving a deployment to a different version is permission-checked#

Changing which code a deployment runs is not an ordinary settings change. A deployment runs as its own machine identity, with its own permissions — so repointing it means deciding that new code may act with those permissions.

Whoever repoints it therefore has to hold every permission that identity holds. Without that, the change is refused rather than silently granting the new code an authority its author did not have.

This applies to every path that changes the pinned version, including editing the deployment directly.

Discarding a draft#

A published version is permanent — it is what some deployment may still be running, and what a past execution ran. There is no way to delete one.

The draft can be discarded, which returns the flow to its active version. Two things stop that from being destructive by surprise:

• A flow that has never been published refuses, because discarding its only version would leave nothing behind. Delete the flow instead.
• A draft with a test run still in progress refuses until that run is cancelled.

Libraries#

A flow whose kind is library is versioned and published the same way, but it is never deployed and never bundled on its own. It becomes READY on publish, and workspace flows import it as lib:<name>. Updating a library means publishing it, then republishing the flows that use it — a published bundle holds the code it was built with.

Next#

• Limits and concurrency — what a deployment may consume.
• Held deliveries — switching one off safely.