Using Protected Environments and Manual Approvals in GitLab CI/CD Pipelines

In automated development workflows, manual steps are often seen as inefficient, but for CI/CD pipelines a manual job can be an effective way to enforce deployment controls and meet compliance requirements. This guide shows how to define manual jobs for two key scenarios: controlling who can deploy and adding manual approval steps.

Deployment Environment Protection

Deploying to production is critical and should be protected. Projects with Kubernetes clusters benefit from continuous deployment (CD) models where merges trigger automatic production deployments. For projects without CD, a manual job can control product deployment, but without safeguards it poses a high risk of accidental production releases.

GitLab’s protected environments feature allows you to restrict deployment access to specific roles, groups, or users. By referencing a protected environment in a manual job, you limit who can run the job. Example configuration:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - master

The environment keyword points to a protected environment defined in project settings, containing an allowed user list. Users without permission see a disabled button and cannot execute the job.

Add Approval Step

Some pipeline activities may require explicit approval before execution, even if they are not deployment steps. By adding an approve stage, you can prompt authorized users to continue the pipeline. Example YAML with an approval stage:

stages:
  - build
  - approve
  - deploy

build:
  stage: build
  script:
    - echo Hello!

approve:
  stage: approve
  script:
    - echo Hello!
  environment:
    name: production
    url: https://example.com
  when: manual
  allow_failure: false
  only:
    - master

deploy:
  stage: deploy
  script:
    - echo Hello!
  environment:
    name: production
    url: https://example.com
  only:
    - master

Setting allow_failure: false makes the manual job a blocking step, pausing the pipeline until an authorized user clicks the start button. Only users listed for the environment can approve, providing a robust compliance mechanism.

What Is GitOps?

GitOps extends the idea of describing infrastructure as code, merging development and operations practices. By using a shared Git repository as the single source of truth for both application and infrastructure definitions, teams can apply familiar development workflows—branching, pull requests, and CI/CD—to manage modern cloud‑native platforms such as Kubernetes and serverless.

Version control and continuous integration become the foundation for reliable software delivery. With GitOps, any infrastructure change is committed alongside application changes, enabling synchronized deployments and fostering collaboration between developers and operators.

Why Choose GitOps?

Organizations are adopting GitOps because it ties business agility directly to the ability to deliver high‑quality software quickly. By integrating change management into Git workflows, GitOps streamlines processes, improves traceability, and supports efficient, scalable operations for modern software enterprises.