GitLab protected environments: who can deploy to production

A GitLab protected environment limits deploy jobs to an explicit list of roles, groups or users, so someone who can merge code cannot necessarily deploy it. It requires Premium or Ultimate. Set a short Allowed to deploy list for production and add approvers if you want a second person involved.

What it protects

GitLab's documentation says protected environments restrict who can deploy to sensitive environments such as production. Unauthorized users cannot change critical environments. Administrators can use all environments, including protected ones.

It is part of CI/CD settings, so if CI/CD is turned off for a project, protected environments are unavailable in the UI and API.

Who can be on the list

• By role: Maintainers, or Maintainers and Developers.
• By invited groups.
• By specific users with the Developer, Maintainer or Owner role.

Reporters can only get access through group membership. Changing attributes like external_url, tier or description also requires being on the list.

Deployment only access

This one is neat. Invited groups with the Reporter role can deploy to a protected environment without push or merge access to the deployed branch. That lets you separate release engineers from code authors.

Developers on the list who also have push or merge access to the deployed branch can additionally stop or delete the environment and create an environment terminal. Keep that in mind when you build the list.

Approvals

Approvers can be chosen by role, user or group. Groups must be invited to the project, and approvers need Developer, Maintainer or Owner. The number of required approvals in a rule cannot exceed the number of members in it.

Configuring it

In the UI: project Settings, CI/CD, expand Protected environments, select Protect an environment, choose the environment, set the Allowed to deploy list and approvers, then Protect. You need at least the Maintainer role. There is an API too, and group level protection uses deployment tiers instead of names.

Notes:

• Unprotecting an environment deletes all its access entries.
• Group level protection overrides subgroup settings. If both exist, a user must be allowed by both.

Pair it with the rest of the chain

Protected environments control who deploys. They do not control which code is on the branch, so combine them with protected branches and approval rules. Production credentials should be protected variables, available only on protected branches.

A review checklist

1. Which environments are protected? Is production one of them?
2. Who is on each list, and why?
3. Is there a separate approver, not only the deployer?
4. Are credentials scoped to the same branches?
5. When did you last remove someone who changed teams?

Safeguard policies and gates can add a vulnerability check before the deploy job. See the free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Protected environments

Last reviewed: 19 October 2026.