Pré-requisitos

Antes que o Airframe possa construir qualquer coisa, uma organização precisa de algumas contas em serviços externos e de umas poucas decisões que depois são difíceis de mudar. Esta página lista essas contas e decisões, junto com quanto a plataforma custa enquanto está ociosa, para que você possa planejar o bootstrap e o orçamento dele antes do primeiro passo.

O Airframe é uma implementação de referência, construída e operada em uma única organização. Suas raízes e seus pipelines chamam os projetos e os buckets dessa organização pelos seus identificadores, como o projeto de execução padrão lk-runtime-ivww na raiz de rede do landing-zone. Adotá-lo significa fazer cópias dos sete repositórios e trocar esses valores pelos seus. Estas páginas descrevem como o Airframe foi colocado em funcionamento e como ele funciona hoje.

O que você precisa

Uma organização do Google Workspace, em um domínio que você controla. O Workspace fornece o nó de organização no topo do Google Cloud, as contas das pessoas e os grupos do Google que os reconciliadores do catálogo preenchem e que o login único consulta. O Airframe só foi operado sobre o Workspace. Você também precisa de acesso ao domínio no registrador: um dos últimos passos do bootstrap passa os servidores de nomes dele para o Cloud DNS.
Uma conta de faturamento do Google Cloud com cota de projetos suficiente. Uma conta de faturamento nova só consegue vincular poucos projetos ao faturamento. A do Airframe vinculava cinco, e só a plataforma precisa de uns dez, antes de qualquer produto. Peça mais ao Google no primeiro dia: o Airframe pediu trinta em 2026-09-04, e o Google aumentou a cota para catorze em 2026-09-09. Cada produto faturado ocupa mais dois, e por isso faturar um produto é uma decisão própria.
Um grupo de primeiro nível no GitLab.com, com o GitLab Ultimate. O Airframe é dono do seu grupo, projectairframe, e usa as políticas de segurança do Ultimate para adicionar os jobs que nenhum repositório consegue remover e para exigir a aprovação do controle de aprovação. Ele roda no período de teste do Ultimate enquanto o pedido ao programa Open Source do GitLab está pendente, e todo repositório é público. As raízes do GitLab têm uma chave, gitlab_tier, que deixa de fora os recursos exclusivos do Ultimate. Os substitutos que a especificação prevê para o plano gratuito, contas bot comuns no lugar das contas de serviço do GitLab, estão projetados: hoje nada os cria, então um grupo no plano gratuito não teria contas de fábrica para criar os repositórios dos produtos.
Um stack do Grafana Cloud. O plano gratuito permite um único stack, criado à mão no portal do Grafana, com seus tokens de acesso, durante o bootstrap.
Uma chave do Infracost. O executor calcula o preço de cada plano aprovado com o Infracost. A chave gratuita de um mantenedor, que cobre 1.000 execuções por mês, é adicionada à mão como segredo.
Duas pessoas, ou por enquanto duas contas. Alguns passos precisam de uma segunda pessoa. O Privileged Access Manager nunca deixa quem pede uma concessão de papéis administrativos aprovar o próprio pedido, e o runbook pede que as credenciais de cada conta de administração fiquem com dois mantenedores. Hoje uma só pessoa opera o Airframe, e quem aprova em segundo lugar é a segunda conta do mantenedor: o mecanismo é aplicado, mas a separação entre duas pessoas ainda não é real.

Quanto custa enquanto está ociosa

O README de cada repositório declara o próprio custo permanente. No total, a preço de lista:

Sempre ligado, com a raiz e a chave	Por mês, aprox.
O runner confiável, uma `e2-medium` (control-plane `roots/runner`, `instance_count`, `machine_type`)	USD 24, mais o disco e as imagens em cache
O runner não confiável, uma `e2-medium`, e o Cloud NAT dele (control-plane `roots/runner-untrusted`, `instance_count`)	USD 25, mais o tráfego
A borda compartilhada, um balanceador de carga de aplicativo externo (landing-zone `roots/network`, `edge_enabled`, ligado)	USD 18
O controle de aprovação, uma instância do Cloud Run sempre ativa (control-plane `gate/infra`, `min_instances`)	USD 8
O agente de plataforma de não produção, uma instância pequena (operations `roots/telemetry`, `agent_editions`)	USD 7; o de produção cabe na cota sempre gratuita do Google
O armazenamento da exportação de faturamento (operations `roots/cost`)	centavos

São cerca de USD 82 por mês antes de qualquer produto. O catálogo, o golden-path, o executor e o construtor confiável não custam nada enquanto estão ociosos: o construtor é cobrado por minuto de build. O Grafana Cloud fica no plano gratuito.

Depois, cada produto faturado soma o que executa. O custo estável dele são as duas menores instâncias do Cloud SQL e a instância do seu sandbox, alguns dólares por dia nos tamanhos que a organização de demonstração usa. O catálogo guarda um orçamento mensal para a organização inteira, USD 150 para a organização de demonstração, e o lint do catálogo recusa uma mudança que faça os orçamentos dos produtos e espaços de teste somarem mais do que isso.

As decisões a tomar primeiro

O código da organização. Um código curto vem antes de cada projeto, grupo do Google, rede e bucket de estado: o da organização de demonstração é lk, como em lk-runtime e lk-platform@. Ele está escrito no catalog.yaml e como valor literal nas raízes. A plataforma nunca renomeia nada, porque os nomes são identificadores, então escolha-o uma vez só.

As jornadas e os domínios. São os níveis de cima da hierarquia do catálogo, explicados em como a organização é dividida. Cada domínio recebe uma pasta, um grupo do GitLab, blocos de endereços nas duas redes, uma fábrica de projetos e uma raiz do GitLab próprias, e cada jornada recebe uma zona de DNS. Use nomes curtos: uma jornada tem de 3 a 10 letras e um domínio de 3 a 8, porque o identificador do projeto de um produto, como lk-billing-invoicing-np-7q2m, precisa caber nos 30 caracteres do Google. O plano de endereços da rede tem espaço para oito domínios; um nono exige que o plano seja mudado antes. A organização de demonstração começou com três jornadas de um domínio cada. Adicionar um depois funciona, mas exige vários merge requests na plataforma, como mostra o primeiro domínio.

A região. O Airframe roda em uma só região, us-central1, e o motivo foi o custo: lá valem as cotas sempre gratuitas de computação e armazenamento do Google, e uma segunda região dobraria o que funciona o tempo todo. A região é um valor no catalog.yaml e nas variáveis das raízes. Uma segunda região está projetada: os módulos têm uma opção multi_region que está sempre desligada, e nada constrói uma segunda região.

Os nomes de host. Cada produto responde em <product>.<domain>.<journey>. seguido do domínio de DNS da organização, que para a organização de demonstração é projectairframe.dev. O domínio está escrito na raiz de rede e nas regras de nomes, então ele anda junto com o código.

Quando isso estiver decidido, o bootstrap pode começar.

Onde fica

No repositório landing-zone:

No repositório control-plane:

No repositório operations:

roots/telemetry/README.md: o custo do agente de plataforma