Deploy gate

A deploy gate is a check that decides whether a change may be released into a given environment, such as staging or production. It runs after the code is merged, or as part of the release step, and can stop a deploy that a merge gate would have let through.

What it is

A merge gate asks "is this change good enough for the main branch?". A deploy gate asks a narrower question: "may this change go to this environment now?". Common conditions are environment rules (no automatic deploys to production), promotion order (staging before production), and a fresh look at the change's checks just before release.

Why it matters

Most incidents start with a deploy. Promotion rules catch the release that skipped staging, and environment rules keep automation away from the places where a mistake costs most. With AI agents producing more changes, having the release step check the same evidence as the merge step matters more, not less.

In AI CodeOps

AI CodeOps doesn't deploy to your infrastructure. It gates the change, calls your deploy webhook and records the deployment. There are three deploy gates.

1. The gate on merge. When you merge a session's pull request from the console, the quality gate runs again first. Open high or critical findings, failing tests or an unfinished review stop the merge, and with it the deploy webhook call.

2. Policy rules per environment. A release.deploy rule in the workspace policy is matched on the environment name. This one stops automatic deploys to production:

{ "id": "no-production-deploys", "action": "release.deploy", "resource": "production", "decision": "deny" }

A denied deploy is never sent. It's recorded as canceled, and the row under Release → Deployments shows "not deployed" with the reason. These rules can allow or deny only; they can't wait for an approval.

3. Promotion from CI. Your pipeline can call POST /api/release/check before it deploys, with "requireDeployedTo": "staging". The release is denied unless the change already has a succeeded deployment in staging:

Not yet deployed to "staging" — promote there before releasing

The response carries "priorEnvironmentMissing": { "required": "staging" }. Check allowed and fail the job when it's false.

A deploy sent by webhook stays in progress, because your pipeline can't report its result back. To satisfy the promotion check, record the finished staging deploy by hand (Record deployment, status succeeded, with its commit SHA), and call the check with that commitSHA.

Related terms

• Rollback: what happens after a deploy that should not have gone out.
• Policy engine: where the environment rules live.
• Human-in-the-loop: the approval that comes before the pull request, not before the deploy.