> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vertgroup.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Infraestrutura

> Onde cada componente roda e o modelo de máquina dedicada por automação

## Backend

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.

## Frontend

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.

## Workers

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.

## Máquina dedicada por automação

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.