Requisitos previos

Antes de que Airframe pueda construir algo, una organización necesita algunas cuentas en servicios externos y unas pocas decisiones que luego son difíciles de cambiar. Esta página las enumera, junto con lo que cuesta la plataforma mientras está inactiva, para que puedas planificar el arranque y tu presupuesto antes del primer paso.

Airframe es una implementación de referencia, construida y operada en una sola organización. Sus raíces y sus pipelines nombran los proyectos y los buckets de esa organización por sus identificadores, como el proyecto de ejecución predeterminado lk-runtime-ivww en la raíz de red de landing-zone. Adoptarlo significa tomar copias de los siete repositorios y reemplazar esos valores por los tuyos. Estas páginas describen cómo se puso en marcha Airframe y cómo funciona hoy.

Lo que necesitas

Una organización de Google Workspace, en un dominio que controles. Workspace aporta el nodo de organización en la cima de Google Cloud, las cuentas de las personas y los grupos de Google que llenan los reconciliadores del catálogo y que revisa el inicio de sesión único. Airframe solo se ha operado sobre Workspace. También necesitas acceso al dominio en tu registrador: uno de los últimos pasos del arranque traslada sus servidores de nombres a Cloud DNS.
Una cuenta de facturación de Google Cloud con suficiente cuota de proyectos. Una cuenta de facturación nueva solo puede vincular unos pocos proyectos a la facturación. La de Airframe podía vincular cinco, y la plataforma sola necesita unos diez, antes de cualquier producto. Pídele más a Google el primer día: Airframe pidió treinta el 2026-09-04, y Google subió la cuota a catorce el 2026-09-09. Cada producto facturado ocupa dos más, y por eso facturar un producto es una decisión en sí misma.
Un grupo de primer nivel en GitLab.com, con GitLab Ultimate. Airframe es dueño de su grupo, projectairframe, y usa las políticas de seguridad de Ultimate para agregar los jobs que ningún repositorio puede quitar y para exigir la aprobación de la compuerta de aprobación. Funciona con la prueba de Ultimate mientras su solicitud al programa Open Source de GitLab está pendiente, y cada repositorio es público. Las raíces de GitLab tienen un interruptor, gitlab_tier, que deja afuera los recursos exclusivos de Ultimate. Los reemplazos que la especificación prevé para el nivel gratuito, cuentas bot comunes en lugar de las cuentas de servicio de GitLab, están diseñados: hoy nada los crea, así que un grupo en el nivel gratuito no tendría cuentas de fábrica para crear los repositorios de los productos.
Un stack de Grafana Cloud. El nivel gratuito admite un solo stack, que se crea a mano en el portal de Grafana, con sus tokens de acceso, durante el arranque.
Una clave de Infracost. El ejecutor pone precio a cada plan aprobado con Infracost. La clave gratuita de un mantenedor, que cubre 1.000 ejecuciones al mes, se agrega a mano como secreto.
Dos personas, o por ahora dos cuentas. Algunos pasos necesitan a una segunda persona. Privileged Access Manager nunca deja que quien pide una concesión de roles administrativos la apruebe, y el runbook pide que las credenciales de cada cuenta de administración las tengan dos mantenedores. Hoy una sola persona opera Airframe, y quien aprueba en segundo lugar es la segunda cuenta del mantenedor: el mecanismo se aplica, pero la separación entre dos personas todavía no es real.

Lo que cuesta mientras está inactiva

El README de cada repositorio declara su propio costo permanente. En conjunto, a precio de lista:

Siempre encendido, con su raíz y su interruptor	Por mes, aprox.
El runner de confianza, una `e2-medium` (control-plane `roots/runner`, `instance_count`, `machine_type`)	USD 24, más su disco y las imágenes en caché
El runner sin confianza, una `e2-medium`, y su Cloud NAT (control-plane `roots/runner-untrusted`, `instance_count`)	USD 25, más el tráfico
El borde compartido, un balanceador de carga de aplicaciones externo (landing-zone `roots/network`, `edge_enabled`, encendido)	USD 18
La compuerta de aprobación, una instancia de Cloud Run siempre activa (control-plane `gate/infra`, `min_instances`)	USD 8
El agente de plataforma de no producción, una instancia pequeña (operations `roots/telemetry`, `agent_editions`)	USD 7; el de producción entra en el nivel siempre gratuito de Google
El almacenamiento de la exportación de facturación (operations `roots/cost`)	centavos

Son unos USD 82 al mes antes de cualquier producto. El catálogo, golden-path, el ejecutor y el constructor de confianza no cuestan nada mientras están inactivos: el constructor se cobra por minuto de compilación. Grafana Cloud se queda en su nivel gratuito.

Después, cada producto facturado suma lo que ejecuta. Su costo estable son sus dos instancias de Cloud SQL más pequeñas y la instancia de su sandbox, unos pocos dólares al día con los tamaños que usa la organización de demostración. El catálogo guarda un presupuesto mensual para toda la organización, USD 150 para la organización de demostración, y el lint del catálogo rechaza un cambio que haga que los presupuestos de sus productos y espacios de prueba sumen más.

Las decisiones que conviene tomar primero

El código de la organización. Un código corto va delante de cada proyecto, grupo de Google, red y bucket de estado: el de la organización de demostración es lk, como en lk-runtime y lk-platform@. Está escrito en catalog.yaml y como valor literal en las raíces. La plataforma nunca cambia el nombre de nada, porque los nombres son identificadores, así que elige el código una sola vez.

Los recorridos y los dominios. Son los niveles superiores de la jerarquía del catálogo, explicados en cómo se divide la organización. Cada dominio recibe una carpeta, un grupo de GitLab, bloques de direcciones en las dos redes, una fábrica de proyectos y una raíz de GitLab propias, y cada recorrido recibe una zona DNS. Usa nombres cortos: un recorrido tiene de 3 a 10 letras y un dominio de 3 a 8, porque el identificador del proyecto de un producto, como lk-billing-invoicing-np-7q2m, tiene que caber en los 30 caracteres de Google. El plan de direcciones de la red tiene lugar para ocho dominios; un noveno necesita que antes se cambie el plan. La organización de demostración empezó con tres recorridos de un dominio cada uno. Agregar uno después funciona, pero lleva varios merge requests en la plataforma, como muestra el primer dominio.

La región. Airframe funciona en una sola región, us-central1, y la razón fue el costo: allí se aplican los niveles siempre gratuitos de cómputo y almacenamiento de Google, y una segunda región duplicaría lo que funciona todo el tiempo. La región es un valor en catalog.yaml y en las variables de las raíces. Una segunda región está diseñada: los módulos llevan una marca multi_region que siempre está apagada, y nada construye una segunda región.

Los nombres de host. Cada producto responde en <product>.<domain>.<journey>. seguido del dominio DNS de la organización, que para la organización de demostración es projectairframe.dev. El dominio está escrito en la raíz de red y en las reglas de nombres, así que va junto con el código.

Cuando esto esté decidido, puedes empezar el arranque.

Dónde está

En el repositorio landing-zone:

En el repositorio control-plane:

En el repositorio operations:

roots/telemetry/README.md: el costo del agente de plataforma