control-plane

The control-plane repository holds the machinery that turns an approved merge request into a change in the cloud. It contains the gate that judges merge requests, the executor that runs their plans and builds, the pipeline components every repository includes, the policy pack that checks every change, and the Terraform roots that configure GitLab itself from the catalog. When a pipeline on Airframe does something, the code that does it almost always lives here.

What it is for

A product team should not have to write its own deployment pipeline, and should not be able to write one that skips the platform’s checks. control-plane provides the pipeline pieces once, for everyone, together with the two trusted services that do what an untrusted pipeline must not: the gate and the executor. It also keeps GitLab’s configuration, groups, repositories, protections and memberships, in code derived from the catalog.

What is in it

gate/: the gate, a small TypeScript service on Cloud Run. It checks each pipeline’s signed token, evaluates the ownership model, gives or withholds its approval, starts the executor, and sets the cost status check. The gate and the executor page explains it.
executor/: the scripts the trusted runner runs for an approved merge request: plans, pricing, image builds through the trusted builder, previews and their cleanup.
templates/: the pipeline components a repository includes, such as validate, tf-apply (plan, policy and apply on main, and the daily drift plan), image-build, promote-artifact and drift-report.
policy/airframe/: the policy pack, the Rego rules and their tests. See policy as code.
roots/: the roots that configure GitLab from the catalog (gitlab, gitlab-config and one gitlab-config-<journey>-<domain> per domain), and the roots of the trusted runner, the untrusted runner, the executor and the trusted builder.
releases/: the manifests and the list of permitted releases.
cli/: the airframe command: airframe validate, airframe pin and airframe release.
images/: the platform’s base images, which every product Dockerfile must start from, and the images its own jobs run in.
security-policies/: an exact mirror of the GitLab security policies, kept for a future bootstrap: the gitlab root wrote them from here once, and a job, policy:schema, fails when the mirror and the security-policies repository’s main differ.

How it connects

Every repository includes its components. A product’s pipeline file may include only these components, pinned to a release’s commit, so every product’s plans and applies run the same tested code.
It reads the catalog. Its GitLab roots create each product’s repository, protect its main branch, set its merge rights and memberships, and write its first commit from golden-path’s template. They run third in the chain after a catalog merge.
It reads landing-zone’s outputs. The domain roots take each product’s Ready output to render its first commit, and the executor takes a product’s authority from the same publication.
It started security-policies. The gitlab root wrote the group’s security policies once, at the bootstrap; since then a change to a policy is a merge request in security-policies itself.
It is released with four other repositories. golden-path, the modules, security-policies and platform-skills pin a control-plane commit, and a release names them all.

Who changes it, and how

Changes are merge requests approved by the platform team, with the gate’s approval required. On a merge request the pipeline runs the tests of what changed: the policy pack’s tests and fixtures, the executor’s, the components’, the airframe command’s, and the release checks when a release changes. On main, each root plans, passes the policy pack and applies under its own identity; the gate’s service is deployed by its own root the same way.

One root is the exception: roots/gitlab, which holds the GitLab settings fixed at the bootstrap. It is applied from a laptop with the GitLab administrator account’s one-day token, and each run is recorded. Every other GitLab change goes through the pipeline.

Where it lives

In the control-plane repository: