A product's life

This page follows one product through its whole life on Airframe, from the merge request that creates it to the one that removes it. Every step is a merge request or a pipeline that a merge started; nobody creates anything by hand. The example is the demo organization’s orders product, and the times come from the platform’s own rehearsal of 2026-09-20, which took products through the same steps from start to finish.

1. The catalog merge request

A member of the store team adds products/shop.store.ordering.orders.yaml to the catalog: the owning team, the stack, the criticality, the recovery objectives and a monthly budget of 5 US dollars. The catalog’s pipeline checks the file against its schema and its consistency rules.

The product’s team, or the leads of its context or domain, approve it. The gate checks those approvals against the catalog’s ownership model, adds its own, and the merge request can merge.

2. The chain

The merge starts the chain of reconcilers. landing-zone creates the product’s Google group, its two projects, lk-store-orders-<rnd> and lk-store-orders-np-<rnd>, and its plan and apply identities. operations creates its folder, dashboards and alert rules in Grafana. control-plane creates the repository projectairframe/shop/store/ordering/orders, protects its main branch and gives the team its rights.

One note on the catalog merge request follows the chain as it runs, with times and links. In the rehearsal, the chain took about thirty minutes from the merge to the repository.

3. The repository’s first commit

control-plane’s root for the domain renders golden-path’s template with the catalog entry and the project factory’s Ready output as answers, and pushes the result as the repository’s first commit. It is a working application for the chosen stack, its Terraform roots, a pipeline made of the platform’s components, a runbook and instructions for a coding agent.

That first commit has no merge request of its own: its approval is the catalog merge request’s. The gate admits it as a product repository’s first commit rendered from the catalog, the one exception to “only a merged merge request’s commit runs on main”.

From its first merge request, the new repository needs the approval of a named person who did not write the change. The gate’s approval becomes required once the repository joins the gate’s list and the approval policy’s scope, two merge requests in control-plane and security-policies, as the gate’s page explains.

4. Billing

A new product’s projects exist from the start, with their identities and permissions, but they are not linked to billing. Until they are, the product’s pipeline can plan for real and pass the policy pack, and its apply stops at the first service that needs billing, such as Cloud Run.

Billing is a separate merge request in the landing-zone repository that adds the product to the project factory’s list of billed products. It is kept apart on purpose: a billing account can hold only a limited number of billed projects, so taking up that quota is a decision of its own. Once the product is billed, its APIs are enabled, its projects join the shared network, its Google Cloud budgets are created, and the next pipeline applies. Nothing is recreated.

5. The first deploy

The product’s first pipeline on main runs the same steps as every later one: it builds the images on the trusted builder, promotes them, plans each root, runs the policy pack on the plans, and applies them: non-production on its own, and the sandbox before production. Creating the databases takes most of the time.

In the rehearsal, the product answered at its hostname about eighty-five minutes after the catalog entry merged.

6. The hostname behind single sign-on

The product answers at orders.store.shop.projectairframe.dev. Like every hostname on the platform, it sits behind Google’s Identity-Aware Proxy, the platform’s single sign-on: only members of the product’s users group, which the catalog fills, can reach it.

From here on, the team changes its product through merge requests, as a change’s path describes.

7. Retiring

To retire the product, the team changes its status in the catalog to retiring. The merge request needs the lifecycle label and two approvers besides the author: one from the product’s team, and one from the domain’s leads or the platform team.

After the merge, the product’s own pipeline applies the retirement first: its services leave the shared edge and scale to zero. Its projects, databases, buckets and repository are all kept. In the rehearsal, retiring took under thirty minutes. The demo organization’s orders product is in this state today.

8. Removed, and the tombstone

After the retire_after date in the entry, a last lifecycle merge request sets the status to removed and adds the product’s tombstone to retired-names/.

The product’s own pipeline destroys what the product runs, through the product’s own identities. The chain then detaches the projects from the shared network, deletes them, and schedules the repository for deletion. Google Cloud keeps a deleted project recoverable for thirty days.

Google holds on to some network addresses for a while after the services that used them are deleted, so the removal completes on the next chain run after Google releases them: in the rehearsals, half an hour to two hours later. Only a billed product can be removed this way; the platform does not bill a product just to remove it.

The name is never used again: the catalog refuses any new product with it anywhere in the domain.

Where it lives

In the landing-zone repository:

In the catalog repository:

In the control-plane repository:

docs/adr/0024: the progress note on the catalog merge request