Prerequisites

Before Airframe can build anything, an organization needs a few accounts with outside services and a handful of decisions that are hard to change later. This page lists them, with what the platform costs while it sits idle, so you can plan the bootstrap and its budget before the first step.

Airframe is a reference implementation, built and run in one organization. Its roots and pipelines name that organization’s projects and buckets by their identifiers, such as the default runtime project lk-runtime-ivww in landing-zone’s network root. Adopting it means taking copies of the seven repositories and replacing those values with your own. These pages describe how Airframe was started and how it runs today.

What you need

A Google Workspace organization, on a domain you control. Workspace gives the organization node at the top of Google Cloud, the people’s accounts, and the Google groups that the catalog’s reconcilers fill and single sign-on checks. Airframe has only been run on Workspace. You also need access to the domain at its registrar: one of the last bootstrap steps moves its name servers to Cloud DNS.
A Google Cloud billing account with enough project quota. A new billing account can link only a few projects to billing. Airframe’s could link five, and the platform alone needs about ten, before any product. Ask Google for more on the first day: Airframe asked for thirty on 2026-09-04, and Google raised the quota to fourteen on 2026-09-09. Every billed product takes two more, which is why billing a product is a decision of its own.
A top-level GitLab.com group, on GitLab Ultimate. Airframe owns its group, projectairframe, and uses Ultimate’s security policies to add the jobs no repository can remove and to require the gate’s approval. It runs on the Ultimate trial while its application to GitLab’s Open Source Program is pending, and every repository is public. The GitLab roots have a gitlab_tier switch that leaves the Ultimate-only resources out. The specification’s stand-ins for the Free tier, ordinary bot accounts in place of GitLab’s service accounts, are designed: nothing creates them today, so a Free-tier group would have no factory accounts to create product repositories.
A Grafana Cloud stack. The Free tier allows one stack, created by hand in Grafana’s portal with its access tokens during the bootstrap.
An Infracost key. The executor prices every approved plan with Infracost. A maintainer’s free key, which covers 1,000 runs a month, is added by hand as a secret.
Two people, or for now two accounts. Some steps need a second person. Privileged Access Manager never lets a requester approve their own grant for administrative roles, and the runbook asks each administrative account’s credentials to be held by two maintainers. Today one person runs Airframe, and the second approver is the maintainer’s second account: the mechanism is enforced, but the separation between two people is not yet real.

What it costs while idle

Each repository’s README states its own always-on cost. Together, at list price:

What runs all the time, with its root and its switch	About, per month
The trusted runner, one `e2-medium` (control-plane `roots/runner`, `instance_count`, `machine_type`)	USD 24, plus its disk and cached images
The untrusted runner, one `e2-medium`, and its Cloud NAT (control-plane `roots/runner-untrusted`, `instance_count`)	USD 25, plus traffic
The shared edge, one external Application Load Balancer (landing-zone `roots/network`, `edge_enabled`, on)	USD 18
The gate, one warm Cloud Run instance (control-plane `gate/infra`, `min_instances`)	USD 8
The non-production platform agent, one small instance (operations `roots/telemetry`, `agent_editions`)	USD 7; the production one fits Google’s always-free allowance
The billing export’s storage (operations `roots/cost`)	cents

That is about USD 82 a month before any product. The catalog, golden-path, the executor and the trusted builder cost nothing while idle: the builder is billed by the build minute. Grafana Cloud stays on its Free tier.

Each billed product then adds what it runs. Its steady cost is its two smallest Cloud SQL instances and its sandbox’s instance, a few dollars a day at the sizes the demo organization uses. The catalog keeps a monthly budget for the whole organization, USD 150 for the demo organization, and the catalog’s lint refuses a change that makes its products’ and playgrounds’ budgets add up to more.

Decisions to take first

The organization’s code. A short code prefixes every project, Google group, network and state bucket: the demo organization’s is lk, as in lk-runtime and lk-platform@. It is written in catalog.yaml and as a literal value across the roots. The platform never renames anything, because names are identifiers, so choose it once.

The journeys and domains. These are the top levels of the catalog’s hierarchy, explained in how the organization is divided. Each domain gets a folder, a GitLab group, address blocks in both networks, a project factory and a GitLab root of its own, and each journey gets a DNS zone. Keep the names short: a journey is 3 to 10 letters and a domain 3 to 8, because a product project’s identifier, such as lk-billing-invoicing-np-7q2m, must fit Google’s 30 characters. The network’s address plan has room for eight domains; a ninth needs the plan changed first. The demo organization started with three journeys of one domain each. Adding one later works, but takes several platform merge requests, as the first domain shows.

The region. Airframe runs in one region, us-central1, and the choice was cost: Google’s always-free compute and storage allowances apply there, and a second region would double the always-on items. The region is a value in catalog.yaml and in the roots’ variables. A second region is designed: the modules carry a multi_region flag that is always off, and nothing builds a second region.

The hostnames. Every product answers at <product>.<domain>.<journey>. followed by the organization’s DNS domain, which for the demo organization is projectairframe.dev. The domain is written into the network root and the naming rules, so it belongs with the code.

When these are settled, the bootstrap can start.

Where it lives

In the landing-zone repository:

In the control-plane repository:

In the operations repository:

roots/telemetry/README.md: the platform agent's cost