How do GitHub environments keep prod secrets from other branches?

Environment secrets in GitHub are available only to jobs that reference the environment, and only after its protection rules pass. Add a deployment branch or tag rule and required reviewers, and a feature branch cannot reach your production credentials, even if someone edits the workflow file.

Definition

A GitHub environment is a named deployment target, such as staging or production. You can attach secrets, variables, and protection rules to it. A job opts in by naming the environment. GitHub's documentation says environment secrets are only available to workflow jobs that use the environment, and those jobs can only access them after any configured rules, for example required reviewers, pass.

That differs from repository secrets, which any workflow in the repository can request.

The three controls

GitHub notes that name patterns must be configured for branches or tags individually. Secrets are not released before approval: the job waits, and the environment secrets stay withheld until the rules pass.

Why branch rules matter

Required reviewers alone depend on a human noticing what they approve. A branch rule is mechanical. If only the main branch may deploy to production, a job on any other ref is refused regardless of what the workflow file says. The branch rule plus branch protection on main means a change must be reviewed and merged before it can ever reach the production secrets.

GitHub's secure use guidance recommends exactly this pairing: use environments with required reviewers so jobs cannot access environment secrets until someone approves.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how a change waits at a gate until it passes, which is the same shape as an environment waiting for approval.

Steps to set it up

1. Create an environment per target, for example staging and production.
2. Move credentials from repository secrets into the matching environment.
3. Add a deployment branch rule: choose selected branches and tags, then add the main branch or your release tag pattern.
4. Add required reviewers, ideally a small group that is not the author group, and turn on prevent self-review.
5. Reference the environment in the deploy job only.
6. Delete the old repository level copy of the secret and rotate it, since earlier workflows could read it.
7. Test: run the workflow from a feature branch and confirm it is refused.

Plan caveats

Check your plan before relying on this. GitHub says Free users can configure environments only for public repositories. If a repository is converted from public to private, configured protection rules and environment secrets are ignored, and you cannot configure environments in that state. Teams and Pro plans can configure environments for private repositories, with some features limited, so check each feature's own page.

Pair it with OIDC

If the job uses cloud login via OIDC, the environment also shapes the token. A job that references an environment gets a subject of the environment form, so the cloud trust rule can say "only the production environment of this repository". The protection rules then guard the token too.

Quick check

Safeguard policies and gates can hold pull requests until checks pass, and compliance and evidence automation can record approvals as audit evidence. A free scan is at gold.safeguard.sh/scan.

Sources

• GitHub Docs: Managing environments for deployment
• GitHub Docs: Secure use reference
• GitHub Docs: OpenID Connect reference

Last reviewed: 19 October 2026.