Deploying

The preflight checks your deploy must pass, and what happens after you confirm.

Deploying takes the canvas you have been editing and makes it real: it snapshots the definition into an immutable version, migrates your database if it needs to, and starts or replaces the worker pod that streams your data.

The deploy button#

There is one button, at the right of the canvas toolbar, and its label tells you what it is about to do:

Button states
FieldTypeDescription
Finalize & DeploystoppedA cold start. No worker is running; this creates one.
RepublishactiveThe indexer is already running. This rolls your changes out, replacing the pod in place.
Retry Deployerror stateThe previous attempt failed. A redeploy is the only way out of an error state.
Deploying…deployingDisabled while an attempt is in flight. Wait for it to settle.

What happens when you click it#

  1. The canvas is saved

    You never deploy something other than what is on screen. If saving fails, the deploy does not start.

  2. You are shown a deploy preview

    Because deploying can permanently remove an old version, you are told what it will do before anything happens. See below.

  3. Preflight checks run

    Five checks, in order. Any one of them stops the deploy before anything is changed.

  4. Schema changes are confirmed

    If the migration would drop or narrow anything, the deploy is refused and the exact SQL is shown to you. Nothing runs against your database until you approve it. See schema & migrations.

  5. The worker is started

    The status flips to deploying and a command goes to the orchestrator, which creates or replaces your pod. You are redirected to the logs, with a divider drawn at the deploy point.

The preflight checks#

These are the reasons a deploy is turned away, and every one of them has a specific message:

  1. Ownership. You must own the indexer.
  2. Status. A cold deploy is refused if the indexer is already active, paused, or mid-deploy — the message will tell you to use Republish instead. A republish is only refused while another deploy is in flight.
  3. Compiled Wasm. At least one transform node must have been compiled. Without it you get “Wasm binary is missing. Please compile your AssemblyScript code first.”
  4. Credits. A balance at or below zero is rejected with 402 Payment Required and “Insufficient credits to boot worker.” See credits & billing.
  5. Concurrency. A short-lived lock means only one deploy per indexer can be in progress. A second one gets 429 — including a double-clicked button, which is the point.

The deploy preview#

Because version retention is finite, deploying can evict an old version. The preview tells you which of four situations you are in:

Deploy preview states
FieldTypeDescription
CreatingnormalYour canvas differs from the last version, so a new one will be minted. The usual case.
Unchangedno-op versionThe definition is identical to an existing version, so that version is reused and no retention slot is consumed. The worker is still replaced.
EvictingdestructiveRetention is full. The named version will be permanently deleted to make room. You can protect it with Keep Forever and re-check instead.
BlockedrefusedRetention is full and every version is marked Keep Forever. Nothing can be evicted, so the deploy cannot proceed until you unprotect or delete one.

Deploying twice is safe#

Each confirmation carries a single idempotency key, so repeated clicks on Confirm produce one deploy rather than several. Combined with the concurrency lock, an impatient double-click cannot start two workers.

Cold start versus republish#

Both end in the same place — a worker running your latest version — but they start from different states. A cold start creates a pod where there was none. A republish replaces a running one: the old pod is stopped and a new one takes its place.

There is a brief gap during a republish where nothing is streaming. Events that occur in that window are not backfilled, so avoid republishing during activity you cannot afford to miss.

After the deploy#

The status moves from deploying to active once the pod is healthy, or to an error status if it is not. Watch it in the logs — see logs & status. If it fails, troubleshooting lists what each failure means.