Deploying to Production with Approval Gates

Continuous Deployment ships code automatically, but pushing straight to production without any checkpoint is risky. A bad release can affect every user instantly.

An approval gate is a deliberate pause where a human (or an automated check) confirms a deployment should proceed.

• Reduces blast radius of mistakes
• Creates an audit trail of who approved what
• Lets you separate staging from production confidence levels

GitHub Actions has a feature called Environments. An environment (like production) can hold its own secrets, variables, and protection rules.

You reference an environment from a job using the environment key. This is the foundation for adding approval gates.

In the repository settings, under Settings > Environments > production, you can enable Required reviewers.

When a job targets that environment, the workflow run pauses and waits until one of the listed reviewers clicks Approve.

• Up to 6 reviewers can be configured
• Any one approval (by default) unblocks the job
• The approver cannot be the person who triggered the run, depending on settings

Here a build job runs first, then a deploy job depends on it via needs and targets the protected production environment.

The deploy will not start until the required reviewer approves it in the Actions UI.

Besides reviewers, environments support a wait timer. This forces a delay (up to 30 days) before a deployment can proceed.

A short wait timer is useful as a safety cooldown: it gives the team a window to cancel a run before it reaches production.

Environments can restrict which branches are allowed to deploy. For production, you typically only allow main (or release tags).

This prevents an accidental deploy to production from a feature branch.

• Protected branches — only branches with protection rules
• Selected branches — an explicit allow-list or tag pattern

Each environment has its own secrets. A production environment can hold PROD_DB_URL while staging holds STAGING_DB_URL.

Secrets defined on the environment are only available to jobs that target that environment, adding another layer of isolation.

Setting an url on the environment adds a clickable link to the deployment in the GitHub UI and records a deployment object via the Deployments API.

This gives you a visible history: which commit went to production, when, and by whom.

When a gated job is waiting, you will see a yellow Review deployments banner on the workflow run page.

• Open the run in the Actions tab
• Click Review deployments
• Select the environment and click Approve and deploy or Reject

You can also leave a comment explaining the decision.

The strongest production gate combines several rules together:

• Required reviewers (human approval)
• A wait timer (cooldown)
• Branch restrictions (only main)
• Environment secrets (isolation)

Layering these creates a robust promotion process from staging to production.

Sometimes you need an emergency hotfix. Rather than removing protection rules, consider a separate, narrowly scoped hotfix workflow with its own logging and stricter reviewers.

Never disable gates permanently for convenience — that defeats the purpose of the safety mechanism.

Test your understanding of production approval gates.

You learned how to add approval gates for production deployments using GitHub Environments.

• Use the environment key to target a protected environment
• Required reviewers add human approval
• Wait timers add a cooldown window
• Branch restrictions and environment secrets add isolation

Together these gates make promoting from staging to production safe and auditable.