In GitLab CI, how do you give every merge request its own review app environment, and where does the environment name come from?

## The idea GitLab does not have a distinct "review app" object. A review app is a **dynamic environment**: an ordinary deploy job whose `environment:name` contains a CI/CD variable, so the name resolves to something different on every branch, and GitLab therefore tracks one environment per branch instead of one shared environment. ```yaml deploy_review: stage: deploy script: - ./deploy.sh "$CI_ENVIRONMENT_SLUG" environment: name: review/$CI_COMMIT_REF_SLUG url: https://$CI_COMMIT_REF_SLUG.review.example.com on_stop: stop_review auto_stop_in: 3 days ``` The first pipeline on branch `feature/add-login` creates the environment `review/feature-add-login`; later pipelines on the same branch append deployments to it rather than creating new ones, because the name is stable *for that branch*. ## Why `CI_COMMIT_REF_SLUG` and not `CI_COMMIT_REF_NAME` `CI_COMMIT_REF_NAME` is the branch or tag name exactly as Git has it: it can contain slashes, uppercase letters, dots and other characters that are illegal in a DNS label or a Kubernetes object name. `CI_COMMIT_REF_SLUG` is the sanitised form — lowercased, everything outside `0-9` and `a-z` replaced by `-`, trimmed of leading and trailing hyphens, and truncated to a length that fits a DNS label. That is why it is the conventional building block for both the environment name and the hostname. Inside the job you often want the sanitised form of the *environment* rather than of the branch: `CI_ENVIRONMENT_SLUG` is derived from the resolved environment name and is guaranteed unique and DNS-safe, which makes it the natural choice for the namespace, release name, or subdomain the script creates. Because the slug is truncated, two very long branch names can in principle collide onto one environment. Teams that care use the merge request IID (`CI_MERGE_REQUEST_IID`) in the name instead, which is short and unique per project. ## What GitLab gives you in return Once the environment exists and its branch has an open merge request, GitLab shows a **View app** button in the merge request widget pointing at `url`. That button is the actual product value: a designer, a product owner or a QA engineer clicks it and sees the branch running, with no local checkout. The environment also appears on the Environments page — grouped into a `review` folder thanks to the slash in the name — with its own deployment history. ## Controlling when review apps are built Review apps are usually restricted to merge request pipelines, so that pushes to the default branch do not create one and a branch with no open MR does not spend cluster capacity. That gating is expressed with the job's rules — for example, matching on the pipeline source being a merge request event — which is standard job-selection configuration rather than anything specific to environments. A second decision is automatic versus manual creation. Making the deploy job manual means a review app exists only when someone asks for one, which is a real lever when the app is expensive to stand up (large database seed, many services). The cost is a click, and the tendency for reviewers to skip it. ## Teardown belongs in the same job Dynamic environments accumulate. Every merged branch leaves behind a namespace, a DNS record, a database and an environment row unless something removes them, and nothing does that by default. Two keywords in the same `environment:` block are the answer: `on_stop:` naming a job that destroys the infrastructure, and `auto_stop_in:` giving the environment an expiry so a forgotten branch cleans itself up. Writing the create half without the destroy half is the single most common defect in a review-app setup. ## Secrets and forks A review app deploys code from an unmerged branch, so treat the credentials it uses as exposed to whoever can open a merge request. Give the review-app deploy a narrowly scoped credential — one that can write only to the review namespace — rather than the same account that deploys production, and be deliberate about whether pipelines from forks may run it at all. Environment-scoped variables help here, because a value scoped to `review/*` never resolves in a production deploy job and vice versa. ## Data is the hard part The YAML is easy; the data is not. A review app needs a database, and pointing several dozen of them at one shared database means one branch's migration breaks everybody else's review app. The realistic options are a per-environment database seeded from an anonymised snapshot, or a shared read-only dataset with per-environment writes — and both cost storage and start-up time, which is what `auto_stop_in` and manual creation exist to bound.