info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type:concepts, howto
---
---
# Protected environments **(PREMIUM)**
# Protected environments **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6303) in GitLab 11.3.
[Environments](../environments/index.md) can be used for both testing and
production reasons.
[Environments](../environments/index.md) can be used for different reasons:
Because deploy jobs can be raised by different users with different roles, it's
important to be able to protect specific environments from the effects of
unauthorized users.
- Some of them are just for testing.
By default, a protected environment ensures that only people with the
- Others are for production.
appropriate privileges can deploy to it, keeping the environment safe.
Since deploy jobs can be raised by different users with different roles, it is important that
specific environments are "protected" to prevent unauthorized people from affecting them.
By default, a protected environment does one thing: it ensures that only people
with the right privileges can deploy to it, thus keeping it safe.
NOTE:
NOTE:
A GitLab admin is always allowed to use environments, even if they are protected.
GitLab administrators can use all environments, including protected environments.
To protect, update, or unprotect an environment, you need to have at least the
To protect, update, or unprotect an environment, you need to have at least the
[Maintainer role](../../user/permissions.md).
[Maintainer role](../../user/permissions.md).
...
@@ -157,9 +153,9 @@ For more information, see [Deployment safety](deployment_safety.md).
...
@@ -157,9 +153,9 @@ For more information, see [Deployment safety](deployment_safety.md).
## Group-level protected environments
## Group-level protected environments
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215888) in GitLab 14.0. [Deployed behind the `group_level_protected_environments` flag](../../administration/feature_flags.md), disabled by default.
> - Introduced in GitLab 14.0 [with a flag](https://gitlab.com/gitlab-org/gitlab/-/issues/215888) named `group_level_protected_environments`. Disabled by default.
> - [Feature flag `group_level_protected_environments`](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) removed in GitLab 14.3.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) in GitLab 14.3.
> - [Generally Available](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) on GitLab and on GitLab.com in 14.3.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) in GitLab 14.3.
Typically, large enterprise organizations have an explicit permission boundary
Typically, large enterprise organizations have an explicit permission boundary
between [developers and operators](https://about.gitlab.com/topics/devops/).
between [developers and operators](https://about.gitlab.com/topics/devops/).
...
@@ -210,8 +206,8 @@ configured:
...
@@ -210,8 +206,8 @@ configured:
(or above) to the top-level group. They can maintain CI/CD configurations for
(or above) to the top-level group. They can maintain CI/CD configurations for
the higher environments (such as production) in the group-level settings page,
the higher environments (such as production) in the group-level settings page,
which includes group-level protected environments,
which includes group-level protected environments,