Airframe

Why Airframe

Any stack; the golden path is a default

The platform requires a few things of a product: a catalog entry, only the platform's CI components in the pipeline file, a platform base image under every Dockerfile, and a complete label set on every labeled resource. The rest is a default. The template renders a product's first commit; from then on the application, its Dockerfile and its Terraform are the team's to change, under the same checks.

What is required and what is a default

  1. Three stacks out of the box

    The golden path starts from one Copier template that offers three stacks: Java (Spring), Node and Python (FastAPI). The platform renders a new product's repository from it, for the stack its catalog entry names, with the Terraform roots, the Dockerfile and a pipeline made of the platform's components. Every change to the template re-renders all three examples and compares them with the committed ones; each stack's example is built and tested whenever its part of the template or the pipeline changes.

  2. Or your own Dockerfile

    After the first commit the application is the team's: it can change the Dockerfile or add another, listed in .airframe/images.yaml. Every FROM must name one of the platform's base images, pinned: Node, Python, Java, Bun, PostgreSQL and Redis today, and a stack without one asks the platform to add it. The trusted builder builds every listed image at the approval and attests it, as it does the template's. The platform's build and test jobs know only the three template stacks: another stack runs none of them, and its merge requests fail the coverage gate until its catalog entry lowers quality.minimum_coverage, which a team lead or a domain lead approves.

  3. Modules help; raw resources are allowed

    The golden path's Terraform modules encode the patterns, and a product root may declare resources of its own instead. The policy pack warns on every resource a product root declares outside a module and asks for a reason in the merge request; a warning holds nothing back. What the pack denies, it denies however the resource was written: an incomplete label set, public access, or a network or project, which are the platform's.

  4. A service is approved once

    A Google Cloud service beyond the ones every product project gets is approved once, as an entry in the catalog's list of approved services, by the platform team. Any product can then declare it in its entry: a domain lead approves the declaration (the platform team stands in where the lead has no account), and the project factory enables the service's API on the product's billed projects and grants its roles to that product's apply identities alone. Memorystore for Redis is the first.

Required and optional

What the platform requires of a product, beside what it offers as a default, row by row
RequiredOptional
A catalog entryThe stack: Java, Node or Python with the platform's build and tests, or another on a platform base image without them
Includes only the platform's CI components; the team's own jobs cannot deployThe golden path's Terraform modules
A platform base image, pinned, in every FROMThe template's application, the team's to change after the first commit
The platform's labels on every labeled resourceA database, topics, a sandbox, approved services

What makes it true

Each stack is built and tested when its part of the template changes.
golden-path's pipeline re-renders the three examples from the live catalog and requires them to match the committed ones whenever the template, the examples or the pipeline change (template:render). It builds and tests a stack's example (template:test, template:test-python, template:test-java) when that stack's template files, its example or the pipeline change. The demo catalog declares an active product on each stack: tracking on Java, invoicing on Python, tax-rules on Node.
Your own Dockerfile builds on a platform base image.
The pack's Dockerfile rules deny a FROM or a COPY --from outside the platform's base images, one not pinned and one computed from a build argument, in the Dockerfiles .airframe/images.yaml lists. From release 2026.10.01-1, the injected validation runs them on every merge request that changes a listed Dockerfile named Dockerfile, Dockerfile.* or *.Dockerfile, and airframe validate runs them locally. The trusted builder builds and attests exactly that list at the approval.
Raw resources are allowed, with a warning.
The pack warns on every managed resource a product root declares outside a module, asking for a reason in the merge request, and a warning fails nothing. Its deny rules apply to every resource, raw or not, and the types the platform owns, such as networks, projects and perimeters, are denied in a product root.