A API roda em uma máquina na AWS, junto com as peças de que depende: proxy reverso com certificado TLS renovado automaticamente, cache e fila de mensagens. O banco de dados fica separado, em um serviço gerenciado de banco relacional.A infraestrutura é definida como código em duas camadas. A primeira (o bucket de estado e a permissão que dá à automação de deploy acesso à AWS sem chave fixa) é aplicada manualmente, uma única vez. A segunda (a própria máquina, o banco, as regras de rede) é aplicada automaticamente: toda alteração de infraestrutura passa por uma checagem antes de ser aceita, e é aplicada de fato ao entrar na branch principal, sempre a partir de uma máquina fora da própria API, para que uma alteração de infraestrutura nunca dependa da máquina que ela mesma pode estar recriando.O deploy da aplicação em si (a cada mudança de código, não de infraestrutura) roda a partir da própria máquina da API: builda a imagem nova, aplica as migrações de banco pendentes e sobe os containers atualizados.
A interface web do Hub roda na Vercel, não na AWS. Todo envio passa por um build e checagem de lint antes de qualquer deploy: o deploy automático nativo da Vercel foi desligado de propósito para garantir que essa checagem sempre aconteça primeiro. Cada alteração em revisão ganha um endereço de pré-visualização próprio, publicado automaticamente, sem afetar o que já está em produção.
Cada automação tem sua própria máquina na AWS, na mesma região da API, provisionada pelo mesmo modelo reutilizável de infraestrutura como código, adaptado só com os dados daquela automação. A máquina não tem endereço fixo de internet: ela só faz conexões de saída (para a API e para a fila de mensagens), então não precisa ser alcançável de fora, exceto para acesso administrativo, que é restrito por regra de rede própria daquela máquina.Os passos de colocar uma automação nova no ar (registrar o executor de deploy próprio daquela máquina, cadastrar os segredos de deploy, registrar o worker na API) são manuais por decisão, não por falta de automação: são passos que acontecem uma única vez por automação, e automatizá-los exigiria dar à infraestrutura como código acesso a credenciais de curta duração de um jeito que não compensa pela raridade do evento.
Cada automação tem exatamente uma máquina dedicada. Ela é criada uma única vez, no momento em que a automação é registrada, e fica desligada por padrão: liga automaticamente quando chega uma execução para processar, como efeito colateral da criação do job, sem que isso atrase a confirmação de quem disparou. Quem faz essa chamada de ligar é a própria API, usando uma permissão presa à sua própria identidade na AWS, sem credencial separada guardada em lugar nenhum.Hoje não existe desligamento automático por ociosidade: a máquina só desliga quando a automação é desativada. Uma automação que processa execuções esporádicas fica com a máquina ligada entre uma execução e outra, não só durante o processamento. Isso é relevante para quem pensa em custo por automação: não existe uma economia automática de “desligar quando não há trabalho” hoje.
