Por dentro
O que acontece quando você publica
A plataforma não roda o seu código nela mesma. Ela coordena: guarda a configuração, decide o que fazer e manda um motor de execução construir e subir os containers num cluster Docker Swarm. Quem clona o repositório e constrói a imagem é esse motor, com a credencial de leitura gerada na hora, a cada publicação.
Uma publicação é uma linha com número (#1, #2, …) e uma situação. As situações são estas, na ordem: na fila, analisando, construindo, enviando a imagem, agendando, subindo, conferindo, e então no ar ou falhou. Toda publicação chega a no ar ou falhou — nunca fica parada numa situação do meio. Se o processo que a conduzia morrer no caminho, uma varredura que roda de dois em dois minutos pergunta ao motor o que aconteceu de fato, sonda o endereço do serviço, e escreve o desfecho real com o motivo.
Conferir não é formalidade: para uma publicação ser marcada como no ar, o motor tem de dizer que terminou de construir E o endereço do serviço tem de responder por HTTPS com algo abaixo de 500. Build que termina bem e site que não responde é falha, com o motivo tirado do log do motor.
A versão anterior só sai do ar depois que a nova sobe. Publicação que falha não derruba o que estava funcionando.
A sequência, do clique ao site no ar:
Conectar o repositório
Ao escolher o repositório, a plataforma lê a árvore de arquivos pela API do GitHub — sem clonar — e baixa só os manifestos (package.json, pyproject.toml, go.mod, composer.json, Dockerfile e afins). Com isso ela adivinha o framework, o construtor e a porta. É uma heurística sobre nomes de arquivo e dependências: acerta na maioria, e quando erra você corrige na tela, tanto na importação quanto depois em Build.
Construir
Com Railpack, o motor examina o projeto e monta a imagem; Nixpacks permanece como opção de compatibilidade quando configurado. Com o construtor Dockerfile, ele usa o seu Dockerfile — e o caminho dele é configurável, o que importa em monorepo. Com site estático, o conteúdo é servido por nginx na porta 80. A imagem construída vai para um registro privado da plataforma, identificada por aquela publicação.
Subir
O motor cria ou atualiza um serviço no Swarm com a imagem nova, as suas variáveis, o limite de CPU e memória do seu plano, a contagem de cópias e, se você definiu, o comando próprio do serviço. As cópias são trocadas uma a uma.
Ligar o endereço
Terminado o deploy, o subdomínio da plataforma é anexado ao serviço no roteador de borda, com certificado emitido automaticamente. Certificado novo pode levar cerca de um minuto para valer.
- O que a plataforma faz sozinha: detectar o tipo do projeto na importação, criar o subdomínio, emitir e renovar o certificado, injetar a URL do banco quando você cria um banco no projeto, republicar o app depois de mudar variável ou ligar banco, reiniciar container que morreu, fechar publicação pendurada, avisar o dono por e-mail quando o app cai e quando volta, e apagar log de publicação com mais de 14 dias.
- O que ela NÃO faz por você: escolher a porta certa quando a detecção errou, rodar migração de banco (isso é do seu processo, na inicialização), guardar arquivo enviado pelo usuário (disco de container é descartável), e manter estado em memória entre cópias.