Advantages, drawbacks, and costs

The real advantages

• Blast radius control: a protection rule prevents an accidental or premature deployment from reaching a sensitive environment — module 3 showed this concretely, not just in theory.
• Secret isolation: a production secret is only exposed to jobs that explicitly reference environment: production — a build/test job never has access to it, even by copy-paste mistake in the workflow.
• Auditability: the Deployments page (module 2) and the approval history give a trace of who approved what and when — useful during an incident or compliance audit.
• Governance without changing workflow code: as observed in module 3, you can tighten or loosen a deployment's governance by changing only the Environment's configuration, without touching the YAML file.

The real drawbacks

• Disproportionate friction if miscalibrated: requiring reviewers on a development Environment slows down every iteration with no matching benefit — protection should be proportional to an environment's actual stakes, not applied uniformly by reflex.
• Environment drift: nothing prevents staging and production from gradually diverging (a forgotten variable, a different dependency version) if each Environment's configuration is changed manually without a shared process.
• Configuration complexity: the more Environments, rules, and scoped secrets there are, the more surface area there is to maintain and understand for someone new joining the project.
• It's not an infrastructure solution: a GitHub Environment governs who can trigger a deployment and with which secrets — it doesn't provision, monitor, or roll back anything itself. It's a control point, not a deployment platform.

The plan cost you need to know

Fact verified against official GitHub documentation (re-check if you're reading this long after it was written — plans change):

"Users with GitHub Free plans can only configure environments for public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored."

"Organizations with GitHub Team and users with GitHub Pro can configure environments for private repositories."

In practice: if your repo is private and you (or your organization) are on a Free plan, you can create an Environment and add secrets to it, but the protection rules and scoped secrets will be silently ignored — which can give a false sense of security if you don't know this. This is why module 1 recommended a public repo for following this course.

A decision, not a reflex

The point isn't "Environments are good" or "Environments are unnecessary overhead" — it's that their benefit entirely depends on context: a production environment with real stakes fully justifies the friction of required reviewers; a disposable development environment doesn't. Module 6 turns this into a concrete decision grid, once module 5 has widened the perspective beyond this single GitHub feature.

What you just did

You can now objectively weigh Environments — real benefits, real drawbacks, and a plan constraint that can silently neutralize the protection you think you've configured. The next module steps outside the strict scope of the GitHub feature to talk about environment strategy in general.