Skip to main content

Deployment pipeline: ship on green

When a merge to main produces a green check and the ship key is on, ship-on-green starts a deploy run automatically. The feature is opt-in per repo — and it opts itself in: landing a valid .slipstream-deploy.json on the default branch turns the ship key on for that repo (slipstream.ship_auto). To keep a deploy recipe without shipping on green, set slipstream.ship.<owner>/<repo>=0. With the ship key off, green checks on main do not trigger deployment.

Legend: a failed deploy stage never takes the previous release down — rollback is flipping the ship key off. Yellow is the opt-in artifact path (below); it never runs unless the repo has artifact mode on.

What a deploy run executes​

The deploy stages for Agentic Pipeline's own repository, rendered from the live deploy recipe:

  1. deploy-dashboard
  2. deploy-control
  3. deploy-mcp-fly
  4. deploy-advisor

Each deploy run executes your repo's own deploy recipe — .slipstream-deploy.json, recipe v2 with kind: "deploy" (see deploy recipes) — fetched at the exact merge commit that went green. A merged edit to the deploy recipe is therefore active for the very next deploy, with no platform release in between. If the file is missing or invalid at that commit, the deploy fails with a terminal failing check; there is no central fallback recipe. The platform labels each deploy with the git commit sha, so you can see exactly which commit is live at any time. If a deploy stage fails, the run stops and the previous release keeps serving traffic — a failed deploy stage never takes the previous release down.

Artifact-first deploys (opt-in)​

An artifact-enabled repo inserts one more run kind before the deploy: an artifact run builds and pushes the repo's images to an immutable, SHA-addressed tag and records each digest in a ledger. Only once that run concludes green does the deploy run start, and it promotes those exact digests instead of building anything itself — see artifact-first CD. Repos that don't opt in are unaffected: their deploy still builds in place, exactly as shown above.

Change-scoped deploys​

A deploy stage can declare the paths its image actually depends on via the SKIP_IF_PATHS_UNCHANGED environment variable (space-separated pathspecs). When none of those paths changed between the currently running release and the commit being deployed, the stage records an intentional skip instead of rolling the service. Merges that don't touch a service's inputs stop rebooting it — and the skip is visible on the run, not silent.

Rollback and safety​

Rollback is turning the ship key off — a config flip, not a code change in your repo. While the ship key is off, green checks on main do not trigger new deploy runs. Deploy runs only start from a green check on the main branch.

Deploy recipes change through a deliberately slower gate than CI recipes: slipstream_recipe_promote with kind: "deploy" always opens a draft PR on a fixed branch, requires explicit confirmation before the PR becomes ready for human merge, and never enables auto-merge. The machines that execute fleet CI are not self-deployed by this pipeline at all; rolling them is a separate, operator-controlled action.