Environment required reviewers and administrator bypass controls for private repositories

[caicai202]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

Hello GitHub Community,

I am evaluating a deployment approval control for a private repository and would appreciate clarification based on current GitHub plan capabilities.

1. For a private repository owned by a personal account on GitHub Free, are GitHub Actions Environments and deployment protection rules available? If not, what is the minimum plan that enables them for private repositories?
2. What is the minimum plan that supports required reviewers and wait timers for private repositories? Do the requirements differ between personal accounts and organizations?
3. On plans that support required reviewers for private repositories, can repository administrators be prevented from bypassing deployment protection rules? Is the no-bypass setting available to all eligible private repositories?
4. Do required reviewers and no-bypass controls prevent all users and automation identities with Actions/workflow write or dispatch capabilities from starting a production deployment without approval? Please describe any exceptions or alternative dispatch paths.
5. Are custom deployment protection rules for private repositories limited to GitHub Enterprise? Are there other supported native options?
6. Could you point me to the current official documentation describing plan eligibility, limitations, and pricing?

I am asking about product capabilities only. I am not requesting account-specific troubleshooting and have intentionally omitted repository names, account identifiers, workflow names, infrastructure details, and secrets.

Thank you.

[100rootrain]

Answers based on the current docs (quotes are from the pages linked at the end):

1. GitHub Free, personal account, private repo: no environments at all.

"Users with GitHub Free plans can only configure environments for public repositories."

The minimum is GitHub Pro (personal) or GitHub Team (organization). That gives you environments, environment secrets and variables, and deployment branch/tag restrictions in private repos, but not the other protection rules.

2. Required reviewers and wait timers in private repos: GitHub Enterprise only.

"If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, required reviewers are only available for public repositories." (same note for wait timers)

Personal accounts top out at Pro, so in practice the repository has to live in an organization on GitHub Enterprise Cloud (or on GHES).

3. Preventing admin bypass: yes. In the environment settings, deselect "Allow administrators to bypass configured protection rules". It's part of the same feature set, so it has the same plan requirement:

"Allowing administrators to bypass protection rules is only available for public repositories for users on GitHub Free, GitHub Pro, and GitHub Team plans."

Also consider "Prevent self-review". By default, a required reviewer can approve a run they triggered themselves, and only one of the (up to 6) reviewers needs to approve.

4. Does it stop every path? It gates every trigger (push, workflow_dispatch, repository_dispatch, re-runs, GitHub Apps, GITHUB_TOKEN). Being able to start a run doesn't let you skip the approval. But it only gates jobs that reference the environment. Exceptions to plan for:

• Workflows without environment:. Anyone with write access can push a branch with a new workflow that deploys without referencing the environment. The gate only means something if the production credentials are reachable only through the environment:
  • put them in environment secrets, not repository or organization secrets, or
  • with OIDC, have the cloud trust policy require the subject repo:OWNER/REPO:environment:production, so tokens from ungated jobs are rejected.
• Deployment branch/tag rules. Without them, any branch can reference the environment, which leaves reviewers as the only check. Restrict it to main or release tags.
• Admins can still edit the environment. The no-bypass setting stops force-deploying, but repo admins and org owners can change or delete the protection rules themselves. That shows up in the audit log, so treat admin as a trusted role.
• Anything outside Actions. People or systems that hold the deploy credentials directly aren't affected at all.

5. Custom deployment protection rules: same as 2. On Free, Pro and Team they're public-repo only, so private repos need Enterprise. The closest native setup on Pro/Team is to restrict the environment to main (or a release tag pattern) and protect that branch with a ruleset requiring an approved PR. The human approval then happens at merge time instead of at deploy time.

6. Docs:

• Deployments and environments (plan notes per feature): https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
• Managing environments (bypass, prevent self-review): https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
• Custom deployment protection rules: https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules
• OIDC subject claims (environment: subject): https://docs.github.com/en/actions/reference/security/oidc
• Plans: https://docs.github.com/en/get-started/learning-about-github/githubs-plans and pricing: https://github.com/pricing

[muhammadsaadjalil]

Hi @caicai202,

The answer from @100rootrain covers the plan limitations and approval controls well. I'd add one important security consideration regarding question 4.

Required reviewers protect deployment jobs that reference the protected environment, but they do not automatically protect every possible route to the production infrastructure.

For stronger enforcement, consider these controls together:

Environment approval: Require approval for jobs using the production environment, where your GitHub plan supports it.

Cloud-side authorization: If using OIDC, configure the cloud provider's trust policy to accept credentials only from the intended repository and protected environment.

Workflow change controls: Protect deployment workflow files and production branches using appropriate repository rulesets and pull request reviews.

Administrative governance: Restrict who can change environment settings, secrets, cloud trust policies, and repository rules.

Independent deployment paths: Audit any external deployment integrations, long-lived credentials, or automation that can reach production without passing through the protected workflow.

For example, an OIDC subject condition can help bind cloud access to a particular GitHub environment:

repo:OWNER/REPO:environment:production

This is an illustrative default subject format; the actual trust policy should match your cloud provider, configured claims, and GitHub OIDC customization.

The key takeaway: Environment reviewers provide an approval gate, while cloud authorization and repository governance determine whether alternative deployment paths remain possible.

Even a no-bypass setting should not be treated as an absolute restriction on repository administrators who can modify the underlying configuration.

Hope this additional distinction is helpful!