GitHub Plans - Do you know which plan you need?

GitHub is generous with public repositories. Branch protection, wikis, GitHub Pages and deployment approvals are all free on open source.

Most work at a company cannot be public. When a repo is private, you lose some of these features. Worse, a few of them look like they work, but do nothing.

Check what your plan includes before you rely on a feature.

What each plan gives you on private repos

All of these are free on public repositories, on any plan.

More build minutes is a good reason to pay. Free gives you 2,000 GitHub Actions minutes a month. Real projects use that up fast. A paid plan gives you more, and lets you buy extra when you need it. That leaves room for automation, testing, deployments and AI workflows.

Protections every repository should have

✅ Enforced branch protection. You need this. Nobody should push straight to main. See do you use branch protection

✅ A deployment approval gate. Highly recommended for enterprise apps. Someone should approve a release before it goes live. It is one more layer of protection. On private repos you need Enterprise Plan to have this feature required reviewers . See do you use gated deployment

Team or Enterprise - which one?

Team is enough for most teams

1. You want branch protection to actually work, plus wikis and Pages on private repos
2. You approve production deploys outside GitHub, or you do not approve them yet
3. You have one organisation, and you are happy to manage access by hand
4. The built-in roles suit you: Read, Triage, Write, Maintain, Admin
5. You only need more build minutes. Buy the minutes. That is much cheaper than upgrading

Enterprise Cloud is for enterprise organisations

Enterprise costs several times more per user. It is built for large companies that need governance and compliance. It is not for small teams. Consider it when:

1. You need approval before a production deploy. This is the main reason to upgrade. It is also the only one you cannot work around on Team
2. You have too many repos to set up one by one. Organisation-level rulesets apply one standard to every repo
3. You want joiners and leavers handled by your identity provider. SAML SSO and SCIM remove the manual step. Today, when someone leaves, their access can stay behind
4. You need a role between Write and Read. Custom roles let you say "can review and merge, but cannot deploy". Without them, anyone who needs a little access gets full write
5. You want internal repos. Everyone in the company can read the code, but the public cannot. Without this, you add people to each private repo by hand. That works, but it is more admin as you add repos
6. You have compliance requirements. Audit log API, IP allow list and a 99.9% uptime SLA are Enterprise only

Move to Enterprise Cloud when several of these apply. One feature on its own is rarely worth the extra cost per user.