The release control plane for coding agents · invite-only
Let your coding agent ship to production — safely
Your agent ships through one tool instead of raw host APIs. Crossfade checks the commit, applies your policy, deploys once, proves each service runs it, and rolls back on its own when something's wrong.
Works with any MCP client, or plain HTTP. Free during early access. The engine will be open source (Apache-2.0); self-hosting arrives with the public repository.
> ship this to production crossfade · ship sha 4f2c9e1 · staging → production ✓ pre-flight checks green on 4f2c9e1 · 2 services changed · no migrations · env in sync ✓ policy routine release — approved by release.yml ✓ api render · runs 4f2c9e1 · /healthz 200 · soak 5m ✓ web cloudflare · runs 4f2c9e1 · canary 15% · soak 5m → 100% ✓ verify production /healthz 200 for 2m shipped r-42 · signed receipt rcpt_9xk2
From shipping CoDirect, our own product, with Crossfade (26 Sep–6 Oct 2026) — Crossfade ships itself the same way.
How a release works
Four steps, every time, whoever starts it
Pre-flight
Checks green on the exact commit, what changed in each service, what every migration does to the running code, and variables set in one environment but not the other. A red check stops the release before anything ships.
Policy
.crossfade/release.ymldecides who approves. Routine releases approve themselves; a schema change or a risky release waits for a person, and the agent is told why.Push once, prove it
One deploy per service, in order. Crossfade confirms each one runs the exact commit — version gates, health gates, then a canary and a soak — before the next one ships.
Verify, or roll back
Production is checked once everything is live. If a gate fails, the whole release rolls back in reverse order by itself, and the agent gets a signed receipt either way.
The agent policy
You write the rules once. The agent ships inside them.
An agents: block in .crossfade/release.yml, reviewed like any other code. When an agent's release meets every condition, it approves itself and the decision is recorded on the release, in the audit log and in its signed receipt.
Anything else waits for the people you name — and the agent is told exactly what's waiting and why, so it stops instead of working around it.
The block is pinned: if an agent edits it, nothing self-approves until a person accepts the change in the console.
# .crossfade/release.yml
agents:
start: true # agents may start releases to production
maxPerDay: 20
rollback: auto # a failed agent release rolls itself back
selfApprove: # routine releases approve themselves when…
maxServices: 2
noMigrations: true # …nothing touches the schema
checks: [build, test]
requireVerify: true # …and production is verified, with rollback on failure
approve: # everything else waits for a person
anyOf: ["@acme/release-leads"]
verify:
gate: { http: { path: /healthz, for: 2m } }
rollbackOn: failure # a failed verification undoes the whole releaseConnect your agent
One endpoint. OAuth, or a token.
claude mcp add --transport http crossfade https://crossfade.sh/mcpClaude Code opens a browser to sign in once; you choose the workspace and what the agent may do.
Then tell your agent: “ship this to production with Crossfade.” It reads /agents.txt for the rest.
What a person still decides
Agents do the routine. People keep the judgement calls.
- Anything with a schema migration, and anything the policy calls risky
- Changes to the agents: block itself — an agent can't widen its own rules
- Fixes that write to production, like setting a production variable
- Lifting a freeze, and rolling back when a host's rules need a judgement call
- Which hosts, repositories and people an agent can reach at all
Platforms
Proven where we ship. More coming.
Coming soon — written, being proven before we offer them:
- Vercel
- Netlify
- Fly.io
- Cloudflare Pages
- Heroku
- Google Cloud Run
- Azure App Service
- DigitalOcean
- Deno Deploy
- Coolify
- Supabase
- Neon
- PlanetScale
- Turso
- Upstash
- Slack
- Sentry
- Datadog
- PagerDuty
- Linear
Early access
Request access
FAQ
Questions
Why not let the agent call the host's API directly?
It can deploy that way, but it can't tell you the release worked. It polls, guesses, and has no way to roll back four services in the right order. Crossfade gives it one tool that answers "is it done, is it healthy, and if not, undo it" — and a policy a person wrote decides what it may ship on its own.
Which agents work with it?
Any MCP client can connect to the hosted endpoint, signing in with OAuth 2.1 or sending a bearer token, and the HTTP API works from any script. Claude Code is what we ship with end to end; other MCP clients, such as Cursor or Codex, use the same standard endpoint.
Can an agent approve its own releases?
Only the ones your agents: block allows, and only when every condition holds: which services ship, no migrations, the named checks green, production verification on. The block is pinned: if an agent edits it, nothing self-approves until a person accepts the change.
What happens when a release fails?
The gate that failed is named, the release rolls back in reverse order when the policy says so, and why_failed tells the agent which check failed, the error lines and what to do next. Production verification catches what staging didn't.
Which hosts are supported?
GitHub, Cloudflare Workers and Render are proven in production, and Railway is in beta. Adapters for Vercel, Netlify, Fly.io and others are written and shown as coming soon until they've shipped real releases.
Is it open source? Can I host it myself?
Not yet. The repository is private today. The engine will be open source (Apache-2.0), and self-hosting arrives with the public repository. Until then, crossfade.sh is us running it for you — invite-only while we onboard teams, and free during early access.