Deploy a partir do GitHub no seu próprio servidor

1. 1Build. O código passa pelo build em um container temporário. Um repositório com Dockerfile usa esse Dockerfile no build. Sem ele, o Railpack descobre como fazer o build para Node, Python, Go, sites estáticos e mais, e o Zelie mostra os comandos de build e de inicialização que ele escolheu.
2. 2Testes. Os testes do projeto rodam na imagem nova, em um container próprio, por no máximo dez minutos. Em projetos Node, o Zelie encontra o script de testes sozinho; qualquer outro comando pode ser definido. Um teste que falha mantém a versão antiga.
3. 3Verificação de saúde. A versão nova inicia ao lado da antiga. Um app com domínio precisa responder no caminho de saúde dele em até um minuto.
4. 4No ar. O tráfego passa para ela. O commit no GitHub é marcado como em build, no ar ou com falha.

Se alguma etapa falhar, a versão antiga continua atendendo e o log mostra o motivo. As imagens das últimas cinco versões que estiveram no ar ficam guardadas, então um rollback leva um ou dois segundos.

Conectar o GitHub cria um GitHub App na sua própria conta ou organização, com acesso só aos repositórios que você escolher. Repositórios privados funcionam. O App pode ler o código e definir o status dos commits, nada mais, e a chave privada dele é criptografada antes de ser guardada.

• Cada push no branch do app faz o deploy dele, se você deixar isso ligado.
• Um push só faz o deploy dos apps configurados para aquele repositório e branch, então um GitHub App atende muitos apps sem que um atrapalhe o outro.
• Cada webhook é verificado com o segredo dele antes de qualquer outra coisa, e uma entrega que chega duas vezes é tratada uma vez só.
• Repositórios públicos fazem deploy sem o App, quando você mesmo inicia o deploy.

Uma imagem de container

Qualquer imagem pública, como nginx:1.27, com domínio e HTTPS próprios. O Zelie verifica o registry uma vez por dia e oferece a imagem nova quando a tag muda.

Os seus próprios arquivos

Escolha Node.js, Python, Bun, Deno ou Java e envie os arquivos, ou mande-os por SFTP. Isso serve para um bot do Discord ou um site pequeno. Aqui não há etapa de build: os arquivos são o app.

Domínio e HTTPS

Instalado com um domínio, o Zelie obtém certificados do Let’s Encrypt. Atrás de um Cloudflare Tunnel, a Cloudflare cuida do HTTPS e nenhuma porta fica aberta no servidor.

Variáveis e segredos

Comuns e secretas, ou um arquivo .env inteiro colado. Um segredo é selado no momento em que é salvo, e os builds recebem as variáveis como segredos do BuildKit, que ficam fora da imagem.

Bancos de dados ao lado

PostgreSQL, MariaDB ou Redis com um clique. Vincular um deles dá ao app DATABASE_URL ou REDIS_URL, e nada mais consegue alcançá-lo.

Logs e métricas ao vivo

Logs de build, de deploy e do app em tempo real. Requisições, erros de servidor, memória, CPU e tráfego, uma leitura por minuto, guardados por um dia.

Crashes tratados

Um app que para sozinho volta, esperando mais depois de cada crash. Depois de cinco crashes em dez minutos, ele fica parado e o painel diz o motivo.

Um container próprio

Rede e namespace de usuário próprios, com limites de memória e CPU. O root dentro do container não é ninguém no servidor.

O Zelie é um único binário, um download de cerca de 50 MB, com o próprio containerd e o estado em SQLite. Os processos dele ficam abaixo de 66 MB de memória em repouso, então uma VPS pequena tem espaço para os apps. Ele roda no Debian ou Ubuntu, amd64 ou arm64, e o mesmo painel pode rodar servidores de jogos ao lado dos seus apps. A diferença em relação ao Coolify está na comparação.

Fazer deploy a cada push exige que o GitHub alcance o painel, o que é possível com um domínio ou um Cloudflare Tunnel. Cada app é uma imagem, um Dockerfile ou uma pasta de arquivos; arquivos do Docker Compose não são lidos.