How each part of Transit reaches production, what triggers it and which checks stand in front of it.

Reference Value
Subject and boundary Release paths for the web Worker, the data proxy, the data edge cache rule and the pipeline. Runtime operation is on ‣.
Verified source web.yml, deploy-data-proxy.yml, configure-data-edge.yml, web-build-artifact.mjs, deploy-scope.mjs, docker-compose.yml, daily-static-pipeline.yml at main 9733eb26d92533f56cdc8bc46b81b93fbb5987c8, checked November 10, 2026. Web run 42415869650 deployed f32cd9b1 to production, and web /health reported commit f32cd9b1 on November 7, 2026. Release paths, deploy-now and rollback re-checked on main 81db4fde on November 10, 2026 (web.yml, deploy-now.yml, rollback.yml); first measured run 42784846952: merge 08:43:18 to the live SHA 08:49:41 UTC, 6m23s (critical path: unit 323 s, ci 13 s, deploy to live 37 s; 8 s from job creation to start, of which the deploy's 4 s may include production-lock or environment scheduling, plus 2 s orchestration); the deploy promoted the merge queue's sealed artifact 13747217869 from queue run 42783253649 and deployed Worker version 0ce0366c-27f8-4246-b5b5-c051c72bec98.
Support state Implemented workflows. Production is the only deployment target. A source revision requires matching workflow and runtime receipts before it can be described as live.

Release paths

Part Trigger Path to production
Web Worker transit-web Push to main, unless every changed path is on the deploy scope's short non-deployable list (deploy-scope.mjs, its test, web.yml and one web test file); manual dispatch. Any other path deploys, including documentation-only changes Since #741 (merged 17:24 UTC on 2026-11-10), a push to main first runs queue-gate: it proves the exact-SHA, same-workflow, first-attempt merge_group run with every required job green and verifies its sealed artifact. When proven, ci-work, unit and core e2e are skipped and deploy production deploys that artifact after the ci aggregate (run 42885842934 on 487ea055: queue-gate success, the three skipped, deploy success). Otherwise it waits for build, unit, core e2e and ci as since #725. It never waits for the layout grid (layout does not run on push). The first measured run 42784846952, before #741, promoted the queue's artifact 13747217869 but still ran unit tests on push, which took most of its 6m23s. The deploy restores the sealed build or the proven queue artifact, applies r2-cors.json to transit-snapshots, runs wrangler deploy and runs apps/data-proxy/smoke.sh against shared routes. Then post-deploy-layout runs the full layout grid on 12 shards (#729) against the deployed SHA, and post-deploy-result reports the result with the rollback command. A failing grid alerts; it never undoes the deploy
Admin deploy now Manual Admin deploy now (deploy-now.yml, #719) with a ref and target web, data-proxy or both Runs on main because the production environment only allows main, keeps main's deployment controls and Wrangler pin, checks out the requested ref, installs, builds and deploys. No test gate. Not yet exercised in production on November 10, 2026
Web preview Pull request from a branch of this repository, except when the workflow actor is dependabot[bot] wrangler versions upload --preview-alias pr-<number> with PUBLIC_INDEXING=false; production traffic is untouched. Fork PRs skip it
Data proxy transit-data-proxy Push to main touching apps/data-proxy/**, .bun-version, .nvmrc, .github/actions/setup/action.yml, .github/workflows/deploy-data-proxy.yml, bun.lock or root package.json Syntax and unit tests, then wrangler deploy in the production environment
Data edge cache rule Manual Configure Data Edge scripts/configure-data-edge.mjs maintains the data.yesid.dev JSON cache rule that respects publisher Cache-Control
Pipeline jobs Each scheduled run checks out main GitHub Actions run transit-ops from the checked-out source. The Daily Static Pipeline runs init-db first, so a merged Alembic migration reaches production on its next run
VM services Operator action on the host worker, pruner, health and postgres images build from apps/db Dockerfiles in the tracked Compose file. The production host override pins image IDs, so a worker rollout builds an image explicitly and edits the override's image lines. No workflow deploys them

The data proxy deploy and the edge configuration share the transit-data-edge-production concurrency group, so they never overlap.

Sealed web build

The web build is made once and the exact bytes are deployed.

Helper command Responsibility
configure Derive production or verification behavior from the workflow event and ref
prepare STAGE Copy the owned build trees (apps/web/.svelte-kit/cloudflare, cloudflare-tmp, output/server) and emit a manifest hash
verify-source STAGE Re-check the seal against the build output after all checks
restore STAGE Validate manifest, context and bytes, then replace only the owned trees

The manifest binds checkout, run and attempt, target, public configuration, tool versions and file bytes. Unsafe paths, links, a context mismatch or a missing artifact stop the restore. Test it locally with node --test .github/scripts/web-build-artifact.test.mjs.

Shared design releases

@yesid/* packages are installed from release tarball URLs of yesid-dev/yesid.design (v0.40.0 since #738, merge 6b5a9c80, 2026-11-10) in the root and web package.json, resolved by bun.lock. Adopting a new design release is one pull request that changes those URLs and the lockfile, then passes the full web workflow, including prerelease-guard, which fails while any design URL points at an -rc tag. Social cards are rendered by Transit's src/lib/og with @yesid/seo-kit fonts; the web workflow runs bun run og:check, and bun run og:build regenerates drifted cards. The pre-commit asset guard accepts bun.lock as the input for regenerated cards.

Rollback

Manual Roll back production web (rollback.yml, #725) moves the web Worker to a given Worker version ID, or to the previous version when the input is blank; post-deploy-result prints the exact command for the version it replaced. It had not been exercised in production on November 10, 2026. The source-backed rollback is still a revert on main that passes the same workflow. A Worker rollback never changes published snapshot data; data recovery is on Recovery, backups and retention.

Publisher rollout boundary

Production realtime workers run image transit-worker:ed25527f, redeployed on November 10, 2026 at 17:52 UTC for #742 (merge commit ed25527f) by recreating only worker and octranspo-worker; pruners and health run bcd815de images. #742 raises the default vehicle speed cap to 130 km/h and needed no database migration; the head stays 0096_provider_live_policy. The previous image, cf5730a8 (redeployed 2026-11-09 19:16 UTC), carried the source-lag change (#704), which also needed none. The payload fields they produce are on Snapshot publication and public contract; the open clean-week proof and crash checks are on Decisions and limitations. No workflow deploys that host. VM activation requires host and payload receipts.

The operator must identify the actual checkout, Compose project and ordered overrides, retain worker image IDs for rollback, build the approved source, and recreate only the two realtime workers. Source changes require an image build and worker recreation; restarting a container uses its existing image. The bounded runbook and acceptance receipts belong to the owning c-t1 slice; this page grants no VM action.

Design releases with API-report or migration-note changes require an rc.N rehearsal in a draft adoption PR in each of the three consumers (Transit, yesid.dev, yesid.login) before stable promotion. In Transit's draft, prerelease-guard and ci fail as expected; after promotion, the same PR switches to the stable URLs, reruns its checks and merges. A consumer pin alone does not prove the shared release or a deployed build.