instruction: Show gitlab_ci configuration examples with best practices
output: Help us learn about your current experience with the documentation. 
  Take the survey
  .
  Environments
  Tier
  : Free, Premium, Ultimate
  Offering
  : GitLab.com, GitLab Self-Managed, GitLab Dedicated
  A GitLab environment represents a specific deployment target for your application, like development, staging, or production. Use it to manage different configurations and deploy code during various stages of your software lifecycle.
  With environments, you:
  Keep your deployment process consistent and repeatable
  Track what code is deployed where
  Roll back to previous versions when problems occur
  Protect sensitive environments from unauthorized changes
  Control deployment variables per environment to maintain security boundaries
  Monitor environment health and get alerts if something goes wrong
  View environments and deployments
  Prerequisites:
  In a private project, you must have at least the Reporter role. See 
  Environment permissions
  .
  There are a few ways to view a list of environments for a given project:
  On the project’s overview page, if at least one environment is available (that is, not stopped).
  
  On the left sidebar, select 
  Operate > Environments
  .
  The environments are displayed.
  To view a list of deployments for an environment, select the environment name,
  for example, 
  staging
  .
  
  Deployments show up in this list only after a deployment job has created them.
  To view a list of all manual jobs in a deployment pipeline, select the 
  Run
   (
  
  play
   
  ) dropdown list.
  Environment URL
  
  History 
  Changed
   to persist arbitrary URLs in GitLab 15.2 
  with a flag
   named 
  soft_validation_on_external_url
  . Disabled by default.
  Generally available
   in GitLab 15.3. 
  Feature flag 
  soft_validation_on_external_url
   removed.
  The 
  environment URL
   is displayed in a few
  places in GitLab:
  In a merge request as a link:
  
  In the Environments view as a button:
  
  In the Deployments view as a button:
  
  You can see this information in a merge request if:
  The merge request is eventually merged to the default branch (usually 
  main
  ).
  That branch also deploys to an environment (for example, 
  staging
   or 
  production
  ).
  For example:
  Go from source files to public pages
  With GitLab 
  Route Maps
  , you can go directly
  from source files to public pages in the environment set for review apps.
  Types of environments
  An environment is either static or dynamic.
  Static environments:
  Are usually reused by successive deployments.
  Have static names. For example, 
  staging
   or 
  production
  .
  Are created manually or as part of a CI/CD pipeline.
  Dynamic environments:
  Are usually created in a CI/CD pipeline and are used by only a single deployment, then either stopped or deleted.
  Have dynamic names, usually based on the value of a CI/CD variable.
  Are a feature of 
  review apps
  .
  An environment has one of three states, depending on whether its 
  stop job
   has run:
  available
  : The environment exists. There might be a deployment.
  stopping
  : The 
  on stop job
   has started. This state does not apply when there is no on stop job defined.
  stopped
  : Either the 
  on stop job
   has run, or a user manually stopped the job.
  Create a static environment
  You can create a static environment in the UI or in your 
  .gitlab-ci.yml
   file.
  In the UI
  Prerequisites:
  You must have at least the Developer role.
  To create a static environment in the UI:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Select 
  Create an environment
  .
  Complete the fields.
  Select 
  Save
  .
  In your 
  .gitlab-ci.yml
   file
  Prerequisites:
  You must have at least the Developer role.
  To create a static environment, in your 
  .gitlab-ci.yml
   file:
  Define a job in the 
  deploy
   stage.
  In the job, define the environment 
  name
   and 
  url
  . If an
  environment of that name doesn’t exist when the pipeline runs, it is created.
  Some characters cannot be used in environment names. For more information about the
  
  environment
   keywords, see the 
  .gitlab-ci.yml
   keyword reference
  .
  For example, to create an environment named 
  staging
  , with URL 
  https://staging.example.com
  :
  deploy_staging
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Deploy to staging server"
  
    
  environment
  :
  
      
  name
  :
   
  staging
  
      
  url
  :
   
  https://staging.example.com
  Create a dynamic environment
  To create a dynamic environment, you use 
  CI/CD variables
   that are
  unique to each pipeline.
  Prerequisites:
  You must have at least the Developer role.
  To create a dynamic environment, in your 
  .gitlab-ci.yml
   file:
  Define a job in the 
  deploy
   stage.
  In the job, define the following environment attributes:
  name
  : Use a related CI/CD variable like 
  $CI_COMMIT_REF_SLUG
  . Optionally, add a static
  prefix to the environment’s name, which 
  groups in the UI
   all
  environments with the same prefix.
  url
  : Optional. Prefix the hostname with a related CI/CD variable like 
  $CI_ENVIRONMENT_SLUG
  .
  Some characters cannot be used in environment names. For more information about the
  
  environment
   keywords, see the 
  .gitlab-ci.yml
   keyword reference
  .
  In the following example, every time the 
  deploy_review_app
   job runs the environment’s name and
  URL are defined using unique values.
  deploy_review_app
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
   
  make deploy
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  https://$CI_ENVIRONMENT_SLUG.example.com
  
    
  rules
  :
  
      
  - 
  if
  :
   
  $CI_COMMIT_BRANCH == "main"
  
        
  when
  :
   
  never
  
      
  - 
  if
  :
   
  $CI_COMMIT_BRANCH
  Set a dynamic environment URL
  Some external hosting platforms generate a random URL for each deployment, for example:
  
  https://94dd65b.amazonaws.com/qa-lambda-1234567
  . That makes it difficult to reference the URL in
  the 
  .gitlab-ci.yml
   file.
  To address this problem, you can configure a deployment job to report back a set of
  variables. These variables include the URL that was dynamically generated by the external service.
  GitLab supports the 
  dotenv (
  .env
  )
   file format,
  and expands the 
  environment:url
   value with variables defined in the 
  .env
   file.
  To use this feature, specify the
  
  artifacts:reports:dotenv
   keyword in 
  .gitlab-ci.yml
  .
  You can also specify a static part of the URL at 
  environment:url
  , such as
  
  https://$DYNAMIC_ENVIRONMENT_URL
  . If the value of 
  DYNAMIC_ENVIRONMENT_URL
   is 
  example.com
  , the
  final result is 
  https://example.com
  .
  The assigned URL for the 
  review/your-branch-name
   environment is visible in the UI.
  
  For an overview, see 
  Set dynamic URLs after a job finished
  .
  In the following example a review app creates a new environment for each merge request:
  The 
  review
   job is triggered by every push, and creates or updates an environment named
  
  review/your-branch-name
  . The environment URL is set to 
  $DYNAMIC_ENVIRONMENT_URL
  .
  When the 
  review
   job finishes, GitLab updates the 
  review/your-branch-name
   environment’s URL.
  It parses the 
  deploy.env
   report artifact, registers a list of variables as runtime-created,
  expands the 
  environment:url: $DYNAMIC_ENVIRONMENT_URL
   and sets it to the environment
  URL.
  review
  :
  
    
  script
  :
  
      
  - 
  DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                
   
  # In script, get the environment URL.
  
      
  - 
  echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env   
   
  # Add the value to a dotenv file.
  
    
  artifacts
  :
  
      
  reports
  :
  
        
  dotenv
  :
   
  deploy.env                                                      
   
  # Report back dotenv file to rails.
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  $DYNAMIC_ENVIRONMENT_URL                                             
   
  # and set the variable produced in script to `environment:url`
  
      
  on_stop
  :
   
  stop_review
  
  stop_review
  :
  
    
  script
  :
  
      
  - 
  ./teardown-environment
  
    
  when
  :
   
  manual
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  Note the following:
  stop_review
   doesn’t generate a dotenv report artifact, so it doesn’t recognize the
  
  DYNAMIC_ENVIRONMENT_URL
   environment variable. Therefore you shouldn’t set 
  environment:url
   in the
  
  stop_review
   job.
  If the environment URL isn’t valid (for example, the URL is malformed), the system doesn’t update
  the environment URL.
  If the script that runs in 
  stop_review
   exists only in your repository and therefore can’t use
  
  GIT_STRATEGY: none
   or 
  GIT_STRATEGY: empty
  , configure 
  merge request pipelines
  
  for these jobs. This ensures that runners can fetch the repository even after a feature branch is
  deleted. For more information, see 
  Ref Specs for Runners
  .
  For Windows runners, you should use the PowerShell 
  Add-Content
   command to write to 
  .env
   files.
  Add-Content
   
  -Path
   
  deploy
  .
  env
   
  -Value
   
  "DYNAMIC_ENVIRONMENT_URL=
  $DYNAMIC_ENVIRONMENT_URL
  "
  Deployment tier of environments
  Sometimes, instead of using an 
  industry standard
  
  environment name, like 
  production
  , you might want to use a code name, like 
  customer-portal
  .
  While there is no technical reason not to use a name like 
  customer-portal
  , the name
  no longer indicates that the environment is used for production. This can affect how metrics
  like 
  deployment frequency
  
  are calculated.
  To indicate that a specific environment is for a specific use,
  you can use tiers:
  Environment tier
  Environment name examples
  production
  Production, Live
  staging
  Staging, Model, Demo
  testing
  Test, QC
  development
  Dev, 
  Review apps
  , Trunk
  other
  By default, GitLab assumes a tier based on 
  the environment name
  .
  You cannot set an environment tier using the UI.
  Instead, you can use the 
  deployment_tier
   keyword
   to specify a tier.
  Rename an environment
  
  History 
  Renaming an environment by using the API was 
  deprecated
   in GitLab 15.9.
  Renaming an environment with the API 
  removed
   in GitLab 16.0.
  You cannot rename an environment.
  To achieve the same result as renaming an environment:
  Stop the existing environment
  .
  Delete the existing environment
  .
  Create a new environment
   with the desired name.
  CI/CD variables
  To customize your environments and deployments, you can use any of the
  
  predefined CI/CD variables
  ,
  and define custom CI/CD variables.
  Limit the environment scope of a CI/CD variable
  By default, all 
  CI/CD variables
   are available to all jobs in a pipeline.
  If a test tool in a job becomes compromised, the tool could attempt to retrieve all
  CI/CD variables available to the job. To help mitigate this kind of supply chain attack,
  you should limit the environment scope of sensitive variables to only the jobs that require them.
  Limit the environment scope of a CI/CD variable by defining which environments it
  can be available for. The default environment scope is the 
  *
   wildcard, so any job
  can access the variable.
  You can use specific matching to select a particular environment. For example, set
  the variable’s environment scope to 
  production
   to only allow jobs with an 
  environment
  
  of 
  production
   to access the variable.
  You can also use wildcard matching (
  *
  ) to select a particular environment group,
  like all 
  review apps
   with 
  review/*
  .
  For example, with these four environments:
  production
  staging
  review/feature-1
  review/feature-2
  These environment scopes match as follows:
  ↓ Scope / Environment →
  production
  staging
  review/feature-1
  review/feature-2
  *
  Match
  Match
  Match
  Match
  production
  Match
  staging
  Match
  review/*
  Match
  Match
  review/feature-1
  Match
  You should not use environment-scoped variables with 
  rules
  
  or 
  include
  . The variables might not be defined when
  GitLab validates the pipeline configuration at pipeline creation.
  Search environments
  
  History 
  Introduced
   in GitLab 15.5.
  Searching environments within a folder
   was introduced in GitLab 15.7 with 
  Feature flag 
  enable_environments_search_within_folder
  . Enabled by default.
  Generally available
   in GitLab 17.4. Feature flag 
  enable_environments_search_within_folder
   removed.
  To search environments by name:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  In the search bar, enter your search term.
  The length of your 
  search term should be 3 or more characters
  .
  Matching applies from the beginning of the environment name.
  For example, 
  devel
   matches the environment name 
  development
  , but 
  elop
   does not.
  For environments with a folder name format, matching applies after the base folder name.
  For example when the name is 
  review/test-app
  , search term 
  test
   matches 
  review/test-app
  .
  Also searching with the folder name prefixed like 
  review/test
   matches 
  review/test-app
  .
  Group similar environments
  You can group environments into collapsible sections in the UI.
  For example, if all of your environments start with the name 
  review
  ,
  then in the UI, the environments are grouped under that heading:
  The following example shows how to start your environment names with 
  review
  .
  The 
  $CI_COMMIT_REF_SLUG
   variable is populated with the branch name at runtime:
  deploy_review
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Deploy a review app"
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  Stopping an environment
  Stopping an environment means its deployments are not accessible on the target server. You must stop
  an environment before it can be deleted.
  When using the 
  on_stop
   action to stop an environment, the job runs if it’s not 
  archived
  .
  Stop an environment by using the UI
  To trigger an 
  on_stop
   action and manually stop an environment from the
  Environments view, the stop and deploy jobs must be in the same
  
  resource_group
  .
  To stop an environment in the GitLab UI:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Next to the environment you want to stop, select 
  Stop
  .
  On the confirmation dialog, select 
  Stop environment
  .
  Default stopping behavior
  GitLab automatically stops environments when the associated branch is deleted or merged.
  This behavior persists even if no explicit 
  on_stop
   CI/CD job is defined.
  However, 
  issue 428625
   proposes to change this behavior
  so that production and staging environments stop only if an explicit 
  on_stop
   CI/CD job is defined.
  You can configure an environment’s stopping behavior with the
  
  auto_stop_setting
  
  parameter in the Environments API.
  Stop an environment when a branch is deleted
  You can configure environments to stop when a branch is deleted.
  In the following example, a 
  deploy_review
   job calls a 
  stop_review
   job to clean up and stop the
  environment.
  Both jobs must have the same 
  rules
  
  or 
  only/except
   configuration. Otherwise,
  the 
  stop_review
   job might not be included in all pipelines that include the
  
  deploy_review
   job, and you cannot trigger 
  action: stop
   to stop the environment automatically.
  The job with 
  action: stop
   might not run
  
  if it’s in a later stage than the job that started the environment.
  If you can’t use 
  merge request pipelines
  ,
  set 
  GIT_STRATEGY
   to 
  none
   or 
  empty
  
  in the 
  stop_review
   job. Then, the 
  runner
   doesn’t
  try to check out the code after the branch is deleted.
  deploy_review
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Deploy a review app"
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  https://$CI_ENVIRONMENT_SLUG.example.com
  
      
  on_stop
  :
   
  stop_review
  
  stop_review
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Remove review app"
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  
    
  when
  :
   
  manual
  Stop an environment when a merge request is merged or closed
  When you use the 
  merge request pipelines
   configuration,
  the 
  stop
   trigger is automatically enabled.
  In the following example, the 
  deploy_review
   job calls a 
  stop_review
   job to clean up and stop
  the environment.
  When the 
  Pipelines must succeed
   setting is turned on,
  you can configure the 
  allow_failure: true
  
  keyword on the 
  stop_review
   job to prevent it from
  blocking your pipelines and merge requests.
  deploy_review
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Deploy a review app"
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  on_stop
  :
   
  stop_review
  
    
  rules
  :
  
      
  - 
  if
  :
   
  $CI_MERGE_REQUEST_ID
  
  stop_review
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
  
      
  - 
  echo "Remove review app"
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  
    
  rules
  :
  
      
  - 
  if
  :
   
  $CI_MERGE_REQUEST_ID
  
        
  when
  :
   
  manual
  When using this functionality together with merge trains, the 
  stop
   job triggers only if 
  duplicate pipelines are avoided
  .
  Stop an environment after a certain time period
  You can set an environment to stop automatically after a certain time period.
  Due to resource limitations, a background worker for stopping environments runs only once every
  hour. This means that environments may not be stopped after the exact time period specified, but are
  instead stopped when the background worker detects expired environments.
  In your 
  .gitlab-ci.yml
   file, specify the 
  environment:auto_stop_in
  
  keyword. Specify the time period in natural language, such as 
  1 hour and 30 minutes
   or 
  1 day
  .
  After the time period passes, GitLab automatically triggers a job to stop the environment.
  In the following example:
  Each commit on a merge request triggers a 
  review_app
   job that deploys the latest change to the
  environment and resets its expiry period.
  If the environment is inactive for more than a week, GitLab automatically triggers the
  
  stop_review_app
   job to stop the environment.
  review_app
  :
  
    
  script
  :
   
  deploy-review-app
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  on_stop
  :
   
  stop_review_app
  
      
  auto_stop_in
  :
   
  1
   
  week
  
    
  rules
  :
  
      
  - 
  if
  :
   
  $CI_MERGE_REQUEST_ID
  
  stop_review_app
  :
  
    
  script
  :
   
  stop-review-app
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  
    
  rules
  :
  
      
  - 
  if
  :
   
  $CI_MERGE_REQUEST_ID
  
        
  when
  :
   
  manual
  The 
  environment:action
   keyword can be used to reset the time
  that an environment is scheduled to stop. For more information, see
  
  Access an environment for preparation or verification purposes
  .
  View an environment’s scheduled stop date and time
  When a environment has been 
  scheduled to stop after a specified time period
  ,
  you can view its expiration date and time.
  To view an environment’s expiration date and time:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Select the name of the environment.
  The expiration date and time is displayed in the upper-left corner, next to the environment’s name.
  Override an environment’s scheduled stop date and time
  When a environment has been 
  scheduled to stop after a specified time period
  ,
  you can override its expiration.
  To override an environment’s expiration in the UI:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Select the environment name.
  in the upper-right corner, select the thumbtack (
  
  thumbtack
   
  ).
  To override an environment’s expiration in the 
  .gitlab-ci.yml
  :
  Open the project’s 
  .gitlab-ci.yml
  .
  Update the 
  auto_stop_in
   setting of the corresponding deploy job to 
  auto_stop_in: never
  .
  The 
  auto_stop_in
   setting is overridden and the environment remains active until it’s stopped
  manually.
  Clean up stale environments
  
  History 
  Introduced
   in GitLab 15.8 
  with a flag
   named 
  stop_stale_environments
  . Disabled by default.
  Generally available
   in GitLab 15.10. Feature flag 
  stop_stale_environments
   removed.
  Clean up stale environments when you want to stop old environments in a project.
  Prerequisites:
  You must have at least the Maintainer role.
  To clean up stale environments:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Select 
  Clean up environments
  .
  Select the date to use for determining which environments to consider stale.
  Select 
  Clean up
  .
  Active environments that haven’t been updated after the specified date are stopped.
  Protected environments are ignored and not stopped.
  Run a pipeline job when environment is stopped
  
  History 
  Feature flag 
  environment_stop_actions_include_all_finished_deployments
   
  introduced
   in GitLab 16.9. Disabled by default.
  Feature flag 
  environment_stop_actions_include_all_finished_deployments
   
  removed
   in GitLab 17.0.
  You can define a stop job for the environment with an 
  on_stop
   action
   in the environment’s deploy job.
  The stop jobs of finished deployments in the latest finished pipeline are run when an environment is stopped. A deployment or pipeline is finished if it has the successful, canceled, or failed status.
  Prerequisites:
  Both the deploy and stop jobs must have the same rules or only/except configuration.
  The stop job must have the following keywords defined:
  when
  , defined at either:
  The job level
  .
  In a rules clause
  . If you use 
  rules
   and 
  when: manual
  , you should
  also set 
  allow_failure: true
   so the pipeline can complete
  even if the job doesn’t run.
  environment:name
  environment:action
  In the following example:
  A 
  review_app
   job calls a 
  stop_review_app
   job after the first job is finished.
  The 
  stop_review_app
   is triggered based on what is defined under 
  when
  . In this
  case, it is set to 
  manual
  , so it needs a
  
  manual action
  
  from the GitLab UI to run.
  The 
  GIT_STRATEGY
   is set to 
  none
  . If the 
  stop_review_app
   job is
  
  automatically triggered
  ,
  the runner doesn’t try to check out the code after the branch is deleted.
  review_app
  :
  
    
  stage
  :
   
  deploy
  
    
  script
  :
   
  make deploy-app
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  https://$CI_ENVIRONMENT_SLUG.example.com
  
      
  on_stop
  :
   
  stop_review_app
  
  stop_review_app
  :
  
    
  stage
  :
   
  deploy
  
    
  variables
  :
  
      
  GIT_STRATEGY
  :
   
  none
  
    
  script
  :
   
  make delete-app
  
    
  when
  :
   
  manual
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  Multiple stop actions for an environment
  
  History 
  Generally available
   in GitLab 15.0. 
  Feature flag 
  environment_multiple_stop_actions
   removed.
  To configure multiple 
  parallel
   stop actions on an environment, specify the
  
  on_stop
   keyword across multiple
  
  deployment jobs
   for the same 
  environment
  , as defined in the
  
  .gitlab-ci.yml
   file.
  When an environment is stopped, the matching 
  on_stop
   actions from only successful deployment jobs are run in parallel, in no particular order.
  All 
  on_stop
   actions for an environment must belong to the same pipeline. To use multiple 
  on_stop
   actions in
  
  downstream pipelines
  , you must configure the environment actions in
  the parent pipeline. For more information, see 
  downstream pipelines for deployments
  .
  In the following example, for the 
  test
   environment there are two deployment jobs:
  deploy-to-cloud-a
  deploy-to-cloud-b
  When the environment is stopped, the system runs 
  on_stop
   actions 
  teardown-cloud-a
   and
  
  teardown-cloud-b
   in parallel.
  deploy-to-cloud-a
  :
  
    
  script
  :
   
  echo "Deploy to cloud a"
  
    
  environment
  :
  
      
  name
  :
   
  test
  
      
  on_stop
  :
   
  teardown-cloud-a
  
  deploy-to-cloud-b
  :
  
    
  script
  :
   
  echo "Deploy to cloud b"
  
    
  environment
  :
  
      
  name
  :
   
  test
  
      
  on_stop
  :
   
  teardown-cloud-b
  
  teardown-cloud-a
  :
  
    
  script
  :
   
  echo "Delete the resources in cloud a"
  
    
  environment
  :
  
      
  name
  :
   
  test
  
      
  action
  :
   
  stop
  
    
  when
  :
   
  manual
  
  teardown-cloud-b
  :
  
    
  script
  :
   
  echo "Delete the resources in cloud b"
  
    
  environment
  :
  
      
  name
  :
   
  test
  
      
  action
  :
   
  stop
  
    
  when
  :
   
  manual
  Stop an environment without running the 
  on_stop
   action
  There may be times when you want to stop an environment without running the defined
  
  on_stop
   action. For example, you want to delete many
  environments without using 
  compute quota
  .
  To stop an environment without running the defined 
  on_stop
   action, execute the
  
  Stop an environment API
   with the parameter
  
  force=true
  .
  Delete an environment
  Delete an environment when you want to remove it and all its deployments.
  Prerequisites:
  You must have at least the Developer role.
  You must 
  stop
   the environment before it can be deleted.
  To delete an environment:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Operate > Environments
  .
  Select the 
  Stopped
   tab.
  Next to the environment you want to delete, select 
  Delete environment
  .
  On the confirmation dialog, select 
  Delete environment
  .
  Access an environment for preparation or verification purposes
  
  History 
  Updated
   to reset 
  auto_stop_in
   for 
  prepare
   and 
  access
   actions in GitLab 17.7.
  You can define a job that accesses an environment for various purposes, such as verification or preparation. This
  effectively bypasses deployment creation, so that you can adjust your CD workflow more accurately.
  To do so, add either 
  action: prepare
  , 
  action: verify
  , or 
  action: access
   to the 
  environment
   section of your job:
  build
  :
  
    
  stage
  :
   
  build
  
    
  script
  :
  
      
  - 
  echo "Building the app"
  
    
  environment
  :
  
      
  name
  :
   
  staging
  
      
  action
  :
   
  prepare
  
      
  url
  :
   
  https://staging.example.com
  This gives you access to environment-scoped variables, and can be used to protect builds from unauthorized access. Also,
  it’s effective to avoid the 
  prevent outdated deployment jobs
   feature.
  If an environment is configured to stop after a certain time period, jobs with the 
  access
   or 
  prepare
  
  action will reset the scheduled stop time. The 
  environment:auto_stop_in
  
  from the most recent successful deployment job to the environment is used when resetting the scheduled time.
  For example, if the most recent deployment used 
  auto_stop_in: 1 week
   and is later accessed by a job with
  
  action: access
  , the environment will be rescheduled to stop one week from the completion of the accessing job.
  To access an environment without changing the scheduled stop time, use the 
  verify
   action.
  Environment incident management
  Production environments can go down unexpectedly, including for reasons outside
  of your control. For example, issues with external dependencies, infrastructure,
  or human error can cause major issues with an environment. Things like:
  A dependent cloud service goes down.
  A 3rd party library is updated and it’s not compatible with your application.
  Someone performs a DDoS attack to a vulnerable endpoint in your server.
  An operator misconfigures infrastructure.
  A bug is introduced into the production application code.
  You can use 
  incident management
  
  to get alerts when there are critical issues that need immediate attention.
  View the latest alerts for environments
  Tier
  : Ultimate
  Offering
  : GitLab.com, GitLab Self-Managed, GitLab Dedicated
  If you 
  set up an alert integration
  ,
  alerts for environments are shown on the environments page. The alert with the highest
  severity is shown, so you can identify which environments need immediate attention.
  When the issue that triggered the alert is resolved, it is removed and is no
  longer visible on the environments page.
  If the alert requires a 
  rollback
  , you can select the
  deployment tab from the environment page and select which deployment to roll back to.
  Auto Rollback
  Tier
  : Ultimate
  Offering
  : GitLab.com, GitLab Self-Managed, GitLab Dedicated
  In a typical Continuous Deployment workflow, the CI pipeline tests every commit before deploying to
  production. However, problematic code can still make it to production. For example, inefficient code
  that is logically correct can pass tests even though it causes severe performance degradation.
  Operators and SREs monitor the system to catch these problems as soon as possible. If they find a
  problematic deployment, they can roll back to a previous stable version.
  GitLab Auto Rollback eases this workflow by automatically triggering a rollback when a
  
  critical alert
  
  is detected.
  For GitLab to select the appropriate environment for the rollback, the alert should contain a 
  gitlab_environment_name
   key with the name of the environment.
  GitLab selects and redeploys the most recent successful deployment.
  Limitations of GitLab Auto Rollback:
  The rollback is skipped if a deployment is running when the alert is detected.
  A rollback can happen only once in three minutes. If multiple alerts are detected at once, only
  one rollback is performed.
  GitLab Auto Rollback is turned off by default. To turn it on:
  On the left sidebar, select 
  Search or go to
   and find your project.
  Select 
  Settings > CI/CD
  .
  Expand 
  Automatic deployment rollbacks
  .
  Select the checkbox for 
  Enable automatic rollbacks
  .
  Select 
  Save changes
  .
  Environment permissions
  Depending on your role, you can interact with environments in public
  and private projects.
  View environments
  In public projects, anyone can view a list of environments, including non-members.
  In private projects, you must have at least the Reporter role to view a list of environments.
  Create and update environments
  You must have at least the Developer role to create a new environment, or update an existing unprotected environment.
  If an existing environment is protected and you don’t have access to it, you cannot update the environment.
  Stop and delete environments
  You must have at least the Developer role to stop or delete an unprotected environment.
  If an environment is protected and you don’t have access to it, you cannot stop or delete the environment.
  Run deployment jobs in protected environments
  If you can push or merge to the protected branch:
  You must have at least the Reporter role.
  If you can’t push to the protected branch:
  You must be a part of a group with the Reporter role.
  See 
  Deployment-only access to protected environments
  .
  Web terminals (deprecated)
  This feature was 
  deprecated
   in GitLab 14.5.
  If you deploy to your environments with the help of a deployment service (for example,
  the 
  Kubernetes integration
  ), GitLab can open
  a terminal session to your environment. You can then debug issues without leaving your web browser.
  The Web terminal is a container-based deployment, which often lacks basic tools (like an editor),
  and can be stopped or restarted at any time. If this happens, you lose all your
  changes. Treat the Web terminal as a debugging tool, not a comprehensive online IDE.
  Web terminals:
  Are available to project Maintainers and Owners only.
  Must 
  be enabled
  .
  In the UI, to view the Web terminal, either:
  From the 
  Actions
   menu, select 
  Terminal
  :
  On the page for a specific environment, on the right, select 
  Terminal
   (
  
  terminal
   
  ).
  Select the button to establish the terminal session.
  It works like any other terminal. You’re in the container created
  by your deployment so you can:
  Run shell commands and get responses in real time.
  Check the logs.
  Try out configuration or code tweaks.
  You can open multiple terminals to the same environment. They each get their own shell
  session and even a multiplexer like 
  screen
   or 
  tmux
  .
  Related topics
  Dashboard for Kubernetes
  Deployments
  Protected environments
  Environments Dashboard
  Deployment safety
  Troubleshooting
  The job with 
  action: stop
   doesn’t run
  In some cases, environments do not stop despite an 
  on_stop
   job being configured. This happens when the job
  with the 
  action: stop
   is not in a runnable state due to its 
  stages:
   or 
  needs:
   configuration.
  For example:
  The environment might start in a stage that also has a job that failed.
  Then the jobs in later stages job don’t start. If the job with the 
  action: stop
  
  for the environment is also in a later stage, it can’t start and the environment isn’t deleted.
  The job with the 
  action: stop
   might have a dependency on a job that has not yet completed.
  To ensure the 
  action: stop
   can always run when needed, you can:
  Put both jobs in the same stage:
  stages
  :
  
    
  - 
  build
  
    
  - 
  test
  
    
  - 
  deploy
  
  ...
  
  deploy_review
  :
  
    
  stage
  :
   
  deploy
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  https://$CI_ENVIRONMENT_SLUG.example.com
  
      
  on_stop
  :
   
  stop_review
  
  stop_review
  :
  
    
  stage
  :
   
  deploy
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  
    
  when
  :
   
  manual
  Add a 
  needs
   entry to the 
  action: stop
   job so the
  job can start out of stage order:
  stages
  :
  
    
  - 
  build
  
    
  - 
  test
  
    
  - 
  deploy
  
    
  - 
  cleanup
  
  ...
  
  deploy_review
  :
  
    
  stage
  :
   
  deploy
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  url
  :
   
  https://$CI_ENVIRONMENT_SLUG.example.com
  
      
  on_stop
  :
   
  stop_review
  
  stop_review
  :
  
    
  stage
  :
   
  cleanup
  
    
  needs
  :
  
      
  - 
  deploy_review
  
    
  environment
  :
  
      
  name
  :
   
  review/$CI_COMMIT_REF_SLUG
  
      
  action
  :
   
  stop
  
    
  when
  :
   
  manual
  Error: job would create an environment with an invalid parameter
  If your project is configured to 
  create a dynamic environment
  ,
  you might encounter this error in a deployment job because the dynamically generated parameter can’t be used for creating an environment:
  This job could not be executed because it would create an environment with an invalid parameter.
  For example, your project has the following 
  .gitlab-ci.yml
  :
  deploy
  :
  
    
  script
  :
   
  echo
  
    
  environment
  :
   
  production/$ENVIRONMENT
  Because the 
  $ENVIRONMENT
   variable does not exist in the pipeline, GitLab tries to
  create an environment with a name 
  production/
  , which is invalid in
  
  the environment name constraint
  .
  To fix this, use one of the following solutions:
  Remove 
  environment
   keyword from the deployment job. GitLab has already been
  ignoring the invalid keyword, therefore your deployment pipelines stay intact
  even after the keyword removal.
  Ensure the variable exists in the pipeline. Review the
  
  limitation on supported variables
  .
  If you get this error on review apps
  For example, if you have the following in your 
  .gitlab-ci.yml
  :
  review
  :
  
    
  script
  :
   
  deploy review app
  
    
  environment
  :
   
  review/$CI_COMMIT_REF_NAME
  When you create a new merge request with a branch name 
  bug-fix!
  ,
  the 
  review
   job tries to create an environment with 
  review/bug-fix!
  .
  However, the 
  !
   is an invalid character for environments, so the
  deployment job fails because it was about to run without an environment.
  To fix this, use one of the following solutions:
  Re-create your feature branch without the invalid characters,
  such as 
  bug-fix
  .
  Replace the 
  CI_COMMIT_REF_NAME
  
  predefined variable
   with
  
  CI_COMMIT_REF_SLUG
   which strips any invalid characters:
  review
  :
  
    
  script
  :
   
  deploy review app
  
    
  environment
  :
   
  review/$CI_COMMIT_REF_SLUG
  
  ## Code Examples
  
  ```text
  deploy_staging:
    stage: deploy
    script:
      - echo "Deploy to staging server"
    environment:
      name: staging
      url: https://staging.example.com
  ```
  
  ```text
  deploy_staging:
    stage: deploy
    script:
      - echo "Deploy to staging server"
    environment:
      name: staging
      url: https://staging.example.com
  ```
  
  ```text
  deploy_review_app:
    stage: deploy
    script: make deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
    rules:
      - if: $CI_COMMIT_BRANCH == "main"
        when: never
      - if: $CI_COMMIT_BRANCH
  ```
  
  ```text
  deploy_review_app:
    stage: deploy
    script: make deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
    rules:
      - if: $CI_COMMIT_BRANCH == "main"
        when: never
      - if: $CI_COMMIT_BRANCH
  ```
  
  ```text
  review:
    script:
      - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
      - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
    artifacts:
      reports:
        dotenv: deploy.env                                                       # Report back dotenv file to rails.
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
      on_stop: stop_review
  
  stop_review:
    script:
      - ./teardown-environment
    when: manual
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
  ```
  
  ```text
  review:
    script:
      - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
      - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
    artifacts:
      reports:
        dotenv: deploy.env                                                       # Report back dotenv file to rails.
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
      on_stop: stop_review
  
  stop_review:
    script:
      - ./teardown-environment
    when: manual
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
  ```
  
  ```text
  Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"
  ```
  
  ```text
  Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    script:
      - echo "Remove review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    script:
      - echo "Remove review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      on_stop: stop_review
    rules:
      - if: $CI_MERGE_REQUEST_ID
  
  stop_review:
    stage: deploy
    script:
      - echo "Remove review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: manual
  ```
  
  ```text
  deploy_review:
    stage: deploy
    script:
      - echo "Deploy a review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      on_stop: stop_review
    rules:
      - if: $CI_MERGE_REQUEST_ID
  
  stop_review:
    stage: deploy
    script:
      - echo "Remove review app"
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: manual
  ```
  
  ```text
  review_app:
    script: deploy-review-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      on_stop: stop_review_app
      auto_stop_in: 1 week
    rules:
      - if: $CI_MERGE_REQUEST_ID
  
  stop_review_app:
    script: stop-review-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: manual
  ```
  
  ```text
  review_app:
    script: deploy-review-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      on_stop: stop_review_app
      auto_stop_in: 1 week
    rules:
      - if: $CI_MERGE_REQUEST_ID
  
  stop_review_app:
    script: stop-review-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: manual
  ```
  
  ```text
  environment_stop_actions_include_all_finished_deployments
  ```
  
  ```text
  environment_stop_actions_include_all_finished_deployments
  ```
  
  ```text
  review_app:
    stage: deploy
    script: make deploy-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review_app
  
  stop_review_app:
    stage: deploy
    variables:
      GIT_STRATEGY: none
    script: make delete-app
    when: manual
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
  ```
  
  ```text
  review_app:
    stage: deploy
    script: make deploy-app
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review_app
  
  stop_review_app:
    stage: deploy
    variables:
      GIT_STRATEGY: none
    script: make delete-app
    when: manual
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
  ```
  
  ```text
  deploy-to-cloud-a:
    script: echo "Deploy to cloud a"
    environment:
      name: test
      on_stop: teardown-cloud-a
  
  deploy-to-cloud-b:
    script: echo "Deploy to cloud b"
    environment:
      name: test
      on_stop: teardown-cloud-b
  
  teardown-cloud-a:
    script: echo "Delete the resources in cloud a"
    environment:
      name: test
      action: stop
    when: manual
  
  teardown-cloud-b:
    script: echo "Delete the resources in cloud b"
    environment:
      name: test
      action: stop
    when: manual
  ```
  
  ```text
  deploy-to-cloud-a:
    script: echo "Deploy to cloud a"
    environment:
      name: test
      on_stop: teardown-cloud-a
  
  deploy-to-cloud-b:
    script: echo "Deploy to cloud b"
    environment:
      name: test
      on_stop: teardown-cloud-b
  
  teardown-cloud-a:
    script: echo "Delete the resources in cloud a"
    environment:
      name: test
      action: stop
    when: manual
  
  teardown-cloud-b:
    script: echo "Delete the resources in cloud b"
    environment:
      name: test
      action: stop
    when: manual
  ```
  
  ```text
  build:
    stage: build
    script:
      - echo "Building the app"
    environment:
      name: staging
      action: prepare
      url: https://staging.example.com
  ```
  
  ```text
  build:
    stage: build
    script:
      - echo "Building the app"
    environment:
      name: staging
      action: prepare
      url: https://staging.example.com
  ```
  
  ```text
  stages:
    - build
    - test
    - deploy
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  stages:
    - build
    - test
    - deploy
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  stages:
    - build
    - test
    - deploy
    - cleanup
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: cleanup
    needs:
      - deploy_review
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  stages:
    - build
    - test
    - deploy
    - cleanup
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: cleanup
    needs:
      - deploy_review
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual
  ```
  
  ```text
  This job could not be executed because it would create an environment with an invalid parameter.
  ```
  
  ```text
  This job could not be executed because it would create an environment with an invalid parameter.
  ```
  
  ```text
  deploy:
    script: echo
    environment: production/$ENVIRONMENT
  ```
  
  ```text
  deploy:
    script: echo
    environment: production/$ENVIRONMENT
  ```
  
  ```text
  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_NAME
  ```
  
  ```text
  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_NAME
  ```
  
  ```text
  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_SLUG
  ```
  
  ```text
  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_SLUG
  ```