Environments and gates: required reviewers, wait timers, and branch protection

The environment is a scoped, gated boundary

A GitHub Environment (production, staging) is two things at once: a scope for secrets and a set of protection rules around any job that targets it. A job opts in with environment: production, and at that moment three things happen. First, the job gains access to environment-scoped secrets — the prod deploy token lives on the environment, not loose in the repo, so only a job that successfully enters production can ever see it. Second, the run pauses before the job starts until every protection rule is satisfied. Third, the deployment is recorded against the environment, giving the audit trail of who deployed what, when. The Hook’s incident is impossible the moment the prod token is environment-scoped and the environment is gated, because there is no longer a path from “trigger a workflow” to “hold the prod credential” that does not pass through the rules.

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production      # scopes secrets + triggers protection rules
    steps:
      - run: ./deploy.sh
        env:
          TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}   # only readable inside `production`

The three protection rules

Each rule closes a different kind of gap. When you see the 2 a.m. incident in the Hook, notice which specific rule would have stopped it — and notice that removing any single rule recreates a version of that gap. The environment’s rules are what convert “a job that can deploy” into “a governed deploy”:

• Required reviewers: the run blocks until a named person or team approves the deployment in the GitHub UI. Critically, the approval is separate from the code review — it gates the act of deploying this run to this environment, and a reviewer who is the deployer typically cannot self-approve, so shipping always needs a second human. This is the rule that the 2 a.m. push bypassed.
• Wait timer: a configurable delay (0–43,200 minutes, i.e. up to 30 days) inserted before the job runs after approval. A short timer — say 10 minutes — creates a deliberate soak/abort window: an obviously-bad release can be cancelled before it touches production, and a canary in front of it has time to report.
• Deployment branches: restrict which branches may deploy to the environment — typically main only (or a release-tag pattern). Combined with branch protection on main (required PR review, required status checks, no direct pushes), this guarantees the only code that can reach production is code that was reviewed and passed CI on the protected branch. The hotfix branch from the Hook would be refused outright.

Together these three rules mean production is not just password-protected — it is structurally unreachable unless code quality, human judgment, and timing all clear. Remove any one and a gap opens — direct-push code, a self-approved deploy, an instant blast — which is precisely the gap the incident fell through.

Required reviewers vs branch protection: two different gates

A common confusion is treating branch protection and required reviewers as redundant. They guard different things. Branch protection governs what code is allowed onto main — it is about the artifact’s trustworthiness and fires at merge time. Required reviewers on the environment governs whether this specific run may deploy now — it is about the act of releasing and fires at deploy time. A change can be perfectly reviewed and merged (branch protection satisfied) and still need a deliberate, separately-approved decision to push it to production during business hours with someone watching (environment reviewer satisfied). You want both because they fail differently: branch protection alone lets any green main commit auto-deploy with no human in the loop at release time; environment review alone lets a human approve deploying code that was never reviewed. The wait timer then adds time to the human gate, and deployment-branch rules bind the two together by ensuring the run being approved actually originates from the protected branch.