Tests every push. Ships every merge.

1. A developer pushes to a fleet repo; the slipstream-k2k GitHub App fires a webhook at the control plane.

2. The control plane verifies the HMAC signature (fail-closed), dedupes the delivery, and persists the run before it acks — a crash can't drop a build.

3. The orchestrator resolves the repo's recipe, checks the allowlist, estimates the queue, and enqueues the run.

4. The scheduler wakes or reuses an executor machine over Fly's Machines API and hands it a single-flight lane.

5. The executor restores the warm workspace, fetches just the new commits, resolves secrets from Infisical, and runs the recipe stages — Turbo scoped to only the changed packages.

6. Logs stream live to object storage; the orchestrator posts the gating RunsGreen check back to the pull request.

7. A green check on main enqueues a deploy run that rolls the dashboard, control plane, and MCP service.

8. Artifact-enabled fleet repos (opt-in, off for RunsGreen itself) insert a THIRD run kind here instead: a green check enqueues an artifact run first, which builds and pushes the repo's images to an immutable SHA-addressed tag and records each digest in a ledger; only once that concludes green is the deploy enqueued, and it promotes those exact digests — never building an image itself. A missing digest refuses the deploy loudly; there is no build-on-miss fallback.

9. For any consumer repo with a live_url configured, a green deploy schedules a live check — up to 5 pings 30s apart against the real public URL — and the outcome (verified / live-unverified / failed) feeds the Fleet page's live milestone; a 15-min sweep re-checks every configured repo (worker pool of 5 concurrent probes) so the page also catches an app going down after deploy. Only the check row matching the latest deployed sha is shown — a stale-sha row from a previous deploy is ignored rather than misreported as verifying the current one.

10. Failure loop: a machine that never reports ready is force-destroyed and replaced; a stalled run raises a plain-English alert; any run can be re-run on demand.

1. A run finishes and the machine stays warm for slipstream.idle_exit_min minutes (2; a busy fleet holds idle_exit_busy_min = 4) so clustered runs skip the wake. Then the executor exits and the machine stops — but a stopped 8 GB machine still reserves its memory against the Fly org overcommit budget (the 2026-07-09 variscreen outage).

2. Retirement is per machine, not whole-fleet silence. A safe started machine idle for slipstream.scaledown_idle_min minutes (30) is stopped with its volume kept; a stopped machine past slipstream.scaledown_destroy_min minutes (60) is destroyed. One removal happens per sweep, and destroy is preferred when both stages are eligible.

3. The default floor is slipstream.min_machines = 2. Setting it to 0 is a deliberate manual scale-to-zero opt-in; automatic retirement still preserves at least one wakeable machine.

4. The rebuild blueprint (slipstream.executor_config_snapshot) is refreshed from a live machine on every healthy 5-minute sweep and every clone scale-up.

5. A push against an empty fleet queues its run; the dispatch lane finds no machine and fires a cold-boot scale-up (rate-limited to one per autoscale_cooldown_s = 90 s). A fresh volume + machine are built from the snapshot — the first run after silence pays ≈1–2 minutes of boot.

6. Under burst, once the oldest waiting run crosses slipstream.autoscale_min_wait_s (20 s), one bounded sequence adds toward every waiting run up to slipstream.max_machines (8). The 90-second cooldown deduplicates overlapping bursts; each new lane is adopted immediately.

7. Executor image rolls are control-plane operations, and routine rolls are zero-downtime: a roll has exactly TWO triggers, both INSIDE the control plane (2026-07-24, superseding the earlier "POST is the sole trigger" ruling): the authenticated POST /api/slipstream/executor-roll, and the flag-gated autoroll reconciler (slipstream.executor_autoroll=1) that rolls to the newest executor image a green self-artifact run genuinely built. What has NOT changed is the load-bearing part: no recipe stage may ever roll the executor or deploy to its app (tests/static/executor-roll-legacy-absence.test.mjs). Either trigger defaults to mode: "generation", which provisions a REPLACEMENT generation (requested → provisioning → verifying → routing → retiring → cleanup → done|failed) instead of draining the fleet: new machines boot on the new image, get health-proven over 6PN, then dispatch atomically starts routing to them while the RETIRING machines keep finishing their in-flight jobs untouched — no admission fence, no paused dispatch. Only the emergency mode: "fenced" path still drains-and-updates in place (requested → draining → rolling → verifying → cleanup → done|failed), guarded by the same leased database admission fence so a run admission and a machine mutation can never win the same race; every Fly stop/update/start renews that fence from a fresh clock immediately before mutation. Either mode resumes from its persisted state after a control restart; lease expiry prevents a dead process from wedging dispatch forever.

8. Safety refusal: automatic retirement never destroys the last wakeable machine. A manual scale-to-zero also refuses unless the rebuild snapshot exists — a fleet that can't rebuild itself must not reach zero (the pre-snapshot unrecoverable-fleet outage).

{
  "version": 1,
  "env": { "CI": "true" },
  "secrets": [
    { "from": "infisical", "projectId": "acd0cd0e-…-73967cea", "env": "prod", "path": "/slipstream" }
  ],
  "stages": [
    { "name": "install",
      "cmd": "bun install --frozen-lockfile && cd dashboard && bun install --frozen-lockfile",
      "timeout_s": 600, "secrets": false },

    { "parallel": [
        { "name": "executor-unit",  "cmd": "bun test slipstream/ --timeout 20000",                        "secrets": false },
        { "name": "driver-scripts", "cmd": "node --test tests/scripts/*.test.mjs tests/static/*.test.mjs", "secrets": false },
        { "name": "workspaces",     "cmd": "bun test packages/ control/ mcp/ && bunx tsc --noEmit -p control && bunx tsc --noEmit -p mcp", "secrets": false },
        { "name": "dashboard",      "cmd": "cd dashboard && bun run test && bun run build", "secrets": false }
    ] },

    { "name": "storage-integration",
      "cmd": "bun test packages/storage/pg.integration.test.ts --timeout 60000",
      "timeout_s": 300, "secrets": true }
  ]
}

Consumers rarely hand-write these — the control plane can translate an existing GitHub Actions workflow into a recipe, dropping steps the runtime already provides (checkout, setup-node, cache) and mapping install actions to commands.

AppHandoff's bounded CI shape: after install, four independent v2 DAG lanes start together — backend, public frontend, portal, and docs. The backend lane keeps its ordered migration, lint/typecheck, API drift, build, and test checks; portal E2E still waits for the portal lane. Conservative if_changed scopes skip unrelated product areas while root manifest changes run every lane. This is how the recipe fits the 6-minute CI ceiling; there is no per-repo exception.

Observe

Act

Recipes

Client surface

Real returns

Both captured live from this fleet on 2026-07-08 (tool names shown in their current slipstream_* form).

{
  "found": true,
  "run_id": "d4ef863a-…",
  "repo": "TeamK2K/slipstream",
  "head_sha": "f73f3970…",
  "state": "success",
  "conclusion": "success",
  "total_s": 53,
  "failed_stage": null,
  "stages": [
    { "name": "deploy-dashboard",  "exit": 0, "duration_s": 28 },
    { "name": "deploy-control",    "exit": 0, "duration_s": 19 },
    { "name": "deploy-mcp-fly", "exit": 0, "duration_s": 12 }
  ],
  "queue": { "pending": 0, "running": 0, "queued": 0, "concurrency": 1 }
}

{
  "found": true,
  "conclusion": "failure",
  "total_s": 25,
  "failed_stage": "storage-integration",
  "failed_stage_exit": 1,
  "stage_timeout_hit": false,
  "budget_kill": false,
  "orchestrator_error": null,
  "error_tail": "… error: expect(received).toEqual(expected)\n +  \"commit_title\": null\n 3 tests failed … [exit 1]",
  "deploy_live_drift": null,
  "next_steps": [
    "Fix stage \"storage-integration\", prove the fix in a sandbox (slipstream_run_sandbox), then land it with slipstream_recipe_promote."
  ]
}

The agent gets the failing assertion and an ordered plan — enough to fix, prove it in a sandbox, and land it without a human in the loop.

Median native CI run per repo (repos with ≥4 runs). The spread reflects each repo's test surface and stack, not fixed overhead — so warm-vs-cold isn't isolated here: per-repo variance dominates the aggregate.

Where the time doesn't go

Suggested rollout