A GitHub environment lets you hold a deploy job until a named reviewer approves it, and keeps that environment's secrets out of reach until then. Add required reviewers, block self-review, and limit which branches can deploy. Check your plan first, because some protections are not available for private repositories on lower tiers.
What an environment gives you
An environment is a named target such as staging or production. A job that references it gets the environment's secrets and variables, and any protection rules run first.
GitHub's documentation says that if an environment requires approval, a job cannot access its secrets until a reviewer approves. That is what makes it more than a label. A malicious or mistaken workflow cannot read production credentials just by existing.
The protection rules
From the documentation:
- Required reviewers. Up to six users or teams. One approval from the list is enough.
- Prevent self-review. Stops the person who started the deployment from approving it.
- Wait timer. A delay from 1 to 43,200 minutes. Handy as a cooling period.
- Deployment branches and tags. No restriction, protected branches only, or selected patterns.
- Admin bypass. Administrators can bypass rules by default, and you can turn that off.
Plan caveats
This is where people get surprised. The docs table says required reviewers and wait timers are not available on Free, Pro or Team for private repositories, only for public ones. Environment secrets need a paid plan for private repositories, and deployment branch rules need Pro or Team.
Confirm your plan on the settings page before building a process around approvals.
A practical setup
- Create a production environment.
- Add a team as reviewer, not one person, so holidays do not block releases.
- Enable prevent self-review.
- Restrict deployments to the protected release branch.
- Store production credentials as environment secrets, not repository secrets.
- Turn off admin bypass if your plan allows it.
In the workflow:
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: ./deploy.sh
Runner caution
The docs note that self-hosted runners are not isolated, so environment secrets on them need the same care as repository and organization secrets. See self-hosted runner risks.
Pair it with short lived cloud access
If the deploy talks to a cloud provider, an environment fits neatly with OIDC. The environment name can appear in the token's subject claim, so the cloud role can trust only that environment. See replacing cloud secrets with OIDC.
Safeguard policies and gates can add a vulnerability check before the approval step. The free scan at gold.safeguard.sh/scan is a quick way to look at what you are about to ship.
Quick check
Can one reviewer approve their own deploy?
Only if prevent self-review is off. Turn it on for production.
Do environment secrets protect against a compromised action?
They limit exposure to jobs that reference the environment and pass approval. A compromised action inside an approved job can still read them.
Sources
Last reviewed: 19 October 2026.
