For a production payments deploy, use a GitHub environment with required reviewers, self-review blocked, deployment limited to your protected branches or tags, and administrator bypass turned off. Optionally add a wait timer. Together these put a human gate and a scope limit in front of production.
What an environment adds
A GitHub Actions environment lets you attach protection rules to a deployment target such as production. A job that references the environment pauses until the rules are met. The GitHub documentation lists the options below.
| Setting | What it does | Why a payments team cares |
|---|---|---|
| Required reviewers | Up to 6 people or teams; one approval lets the job proceed | A human sees every production deploy |
| Prevent self-review | Stops the person who triggered the run from approving it | Real second pair of eyes |
| Wait timer | Delays the job for a number of minutes | Time to catch a mistake or cancel |
| Deployment branches and tags | Limits which refs can deploy to the environment | A feature branch cannot reach production |
| Allow administrators to bypass | Can be deselected | Removes a quiet override path |
| Custom protection rules | Rules built as GitHub Apps | Hooks for your own checks |
Settings worth choosing
Required reviewers. One of the listed reviewers must approve, so name a team that reflects who you trust to judge a payments release, not everyone.
Prevent self-review. Without it, the author of a release can approve their own deploy. Turn it on.
Deployment branches. Choose selected branches and tags and add a rule for your protected release branch pattern. Name patterns need care, so test one that should be refused.
Administrator bypass. Deselect it. If someone must override in an emergency, make that a documented break-glass step with a record afterwards.
Wait timer. The source simply describes it as time to wait before jobs proceed. A short delay can be useful for scheduled releases, but it is optional, and for a hotfix you may need a defined way to skip it.
Secrets live with the environment
Environments can hold their own secrets, separate from repository wide ones. Keep production credentials in the production environment, so jobs that pass its protection rules can read them. This echoes the OWASP advice that CI/CD tooling should use scoped service accounts and that pipeline runs be attributable to the person who triggered them. Combine this with short-lived cloud tokens from OIDC where your provider supports it.
Environment rules are not enough alone
An environment protects the deploy step. It does not review the code. Add required pull request approvals and status checks on the branch, as covered in our post on two-person review. If a workflow file can be changed freely, an attacker with branch access may edit the job that references the protected environment, so keep workflow files under code owner review.
A rollout plan
- Create a staging environment with no reviewers and a production environment with the full set.
- Move production secrets into the production environment.
- Limit deployable refs to your release branch or tags.
- Run a test deploy and confirm it pauses for approval.
- Ask someone who is not an administrator to try to deploy from a feature branch and confirm it fails.
- Record the settings in your change management notes with the date.
Where Safeguard fits
Safeguard's policy gates add dependency and vulnerability checks upstream of the deploy, so the person approving a release sees a cleaner picture. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Try the gates a change must pass before it can reach the deploy step.
Quick check
Do all reviewers have to approve a deployment?
No. According to GitHub, a single approval from one of the required reviewers lets the job proceed.
How many reviewers can be listed?
Up to 6 people or teams.
Sources
Last reviewed: 19 October 2026.
