Skip to main content
Environments in GitLab CI/CD provide isolated stages—development, testing, and production—so teams can build, verify, and release features without affecting live users. By separating concerns, you ensure:
  • Safe feature development
  • Thorough testing before rollout
  • Clear visibility into what version is running
The image illustrates GitLab environments with three stages: Development, Testing, and Production, each represented by a database icon and associated user credentials.
With each environment backed by distinct services (databases, vaults, APIs) and secured via credentials or API keys, GitLab CI/CD helps you:
  • Organize deployments
  • Protect secrets
  • Audit deployment history

Key Concepts

Before exploring environment types, let’s define two fundamental terms:

Environments vs. Deployments

  • Environment: A label representing a deployment target (e.g., development, staging, production).
  • Deployment: An instance of your code pushed to an environment. GitLab tracks each deployment as a record.
Every deployment generates a history entry you can replay or rollback. This audit trail is essential for minimizing downtime and tracking changes over time.
The image shows a GitLab Environments interface with sections for "development" and "staging," displaying deployment details and options to open or stop each environment.
A rollback reverts to a previous deployment, helping you maintain stability when a release fails.

Types of Environments

GitLab supports multiple environment categories. Choose the right one based on your workflow:

Static vs. Dynamic

  • Static Environments:
  • Dynamic Environments:
The image illustrates two types of environments: a "Static Environment" with a graph icon and a "Dynamic Environment" with an atomic symbol.

Review Apps & Protected Environments

  • Review Apps: Spin up an isolated preview for every Merge Request.
  • Protected Environments: Enforce approvals or specific roles before deployment.
The image shows two types of environments: "Review Apps" with a thumbs-up icon and "Protected Environment" with a shield and gear icon.

Securing CI/CD Variables with Environment Scope

By default, all jobs inherit every CI/CD variable. To tighten security and manage configuration:
  • Limit Exposure: Keep production secrets out of development logs.
  • Environment-Specific Settings: Define separate values for each stage.
  • Improve Performance: Smaller variable sets mean faster pipeline startup.
The image illustrates the environment scope for CI/CD variables, highlighting three aspects: Security, Configuration Management, and Improved Pipeline Efficiency, each represented with an icon.

Example: Scoped Variables in GitLab UI

Avoid using the same variable key across environments without scoping—production secrets should never appear in staging or development jobs.
The image shows a table of CI/CD variables with keys, values, environments, and actions, highlighting specific entries for different environments like staging and production.

Further Reading


By leveraging static, dynamic, review, and protected environments—alongside environment-scoped variables—you can build more secure, transparent, and efficient CI/CD workflows in GitLab.

Watch Video