Publicar aplicações
Build packs no Coolify: Railpack, Dockerfile, Compose e imagem pronta
O que muda entre Railpack, Static, Dockerfile, Docker Compose e imagem pronta, quando usar cada um e a porta que cada um espera.
- Nível: Intermediário
- Tempo: cerca de 10 minutos de leitura
- Atualizado em 12/11/2026
- Por equipe técnica da Hospedagem Segura
Conteúdo do guia
Resposta rápida
O build pack diz ao Coolify como transformar o seu código numa imagem. O Railpack, o padrão no Coolify 4.7.5, detecta a linguagem e monta a imagem sozinho. Use Static para site já pronto, Dockerfile para controle total, Docker Compose para vários serviços juntos e Docker Image para imagem pronta de um registro. O Nixpacks está marcado como obsoleto. A porta padrão é 3000 nas aplicações Git e 80 em Static e Docker Image.
O painel do Coolify é em inglês. Neste manual, os botões aparecem como estão na tela, em negrito, com a tradução ao lado. Dúvida com algum termo? Veja o glossário do Coolify em português.
Você vai aprender
- O que cada build pack faz e quando usar
- Trocar o build pack de uma aplicação que já existe
- Criar uma aplicação a partir de Dockerfile ou de imagem Docker pronta
- Acertar a porta de cada build pack e evitar o erro 502
Antes de começar
- Um projeto criado (projetos e ambientes)
- Saber publicar uma aplicação pelo Git (deploy pelo Git)
Neste guia
Os build packs lado a lado
Build pack é a receita que o Coolify usa para montar a imagem da aplicação. Você escolhe ao criar a aplicação e pode trocar depois.
| Build pack | O que faz | Porta padrão | Quando usar |
|---|---|---|---|
| Railpack (padrão) | Detecta a linguagem e o framework e monta a imagem sozinho | 3000 | A maioria das aplicações, quando a detecção reconhece o projeto |
| Nixpacks (deprecated) | O antecessor do Railpack, em modo de manutenção | 3000 | Só aplicações antigas que já usam; o painel recomenda o Railpack |
| Static | Coloca arquivos já prontos num servidor Nginx, sem build | 80 | Site em HTML, CSS e JavaScript já gerado no repositório |
| Dockerfile | Monta a imagem com o Dockerfile do repositório ou escrito no painel | A do primeiro EXPOSE (80 sem EXPOSE) | Quando você quer controle total da imagem |
| Docker Compose | Sobe um ou mais serviços descritos no arquivo Compose | Definida por serviço | Aplicação com vários contêineres: web, fila, cache |
| Docker Image | Não faz build: baixa uma imagem pronta de um registro | 80 | Build pesado ou imagem que já sai pronta da esteira de CI |
A porta precisa bater com a da aplicação
0.0.0.0, não só em 127.0.0.1. Porta errada é a causa mais comum de erro 502 e de No available server.Na dúvida, comece pelo Railpack. Se o build falhar por algo que ele não detecta, passe para Dockerfile.
Railpack: o padrão
O Railpack lê o repositório, descobre a linguagem e o framework e monta a imagem com o BuildKit do Docker. Na maioria dos projetos, basta conferir a porta e a pasta.
Confira o build pack ao criar a aplicação
Depois de Check Repository, o formulário mostra o que o Coolify detectou. Confira cada campo antes de continuar.
- 1Branch: O branch que será publicado (aqui,
main). - 2Build pack: Railpack vem marcado. Troque aqui se o projeto pede outro build pack.
- 3Port:
3000nas aplicações Git. Troque pela porta em que a sua aplicação escuta. - 4Base directory: A pasta da aplicação no repositório.
/quando ela está na raiz. - 5Continue: Cria a aplicação. O build só começa no Deploy.
- 1Branch: O branch que será publicado (aqui,
Troque o build pack de uma aplicação existente
No painel:
Na página da aplicação, a lista Build strategy (estratégia de build) mostra Railpack, Nixpacks (deprecated), Static, Dockerfile e Compose. Depois de trocar, salve as alterações e clique em Redeploy (publicar de novo).
Dica O Railpack aceita ajustes num arquivo
railpack.jsonno repositório e em variáveis que começam comRAILPACK_. Veja variáveis de ambiente.
Por que o Nixpacks aparece como deprecated?
O Nixpacks entrou em modo de manutenção no projeto de origem. O painel o marca como obsoleto e recomenda o Railpack, inclusive para aplicações que já existem.
Dockerfile: controle total da imagem
Com Dockerfile, você decide a imagem base, as dependências e o comando de início. O Coolify usa o Dockerfile do repositório (build pack Dockerfile) ou um Dockerfile escrito direto no painel, sem Git. A porta vem do primeiro EXPOSE; sem EXPOSE, ela é 80.
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]Ou escreva o Dockerfile no painel
No painel:
No ambiente do projeto, clique em New Resource e escolha Dockerfile. Escreva o conteúdo no editor e clique em Create Application (criar aplicação). Sem Git, não há arquivos do repositório para copiar.
Docker Compose: vários serviços juntos
Com Docker Compose, o Coolify sobe todos os serviços do arquivo Compose do repositório, numa rede própria. É o caminho para web, fila e cache que sobem juntos.
- O domínio é ligado por serviço. A porta no domínio, como
https://loja.example.com:3000, indica a porta dentro do contêiner e não abre porta na VPS. - Health check e volumes ficam no próprio arquivo Compose.
- Não há rolling update: os contêineres são trocados de uma vez.
Docker Image: imagem pronta
Docker Image pula o build: o Coolify só baixa a imagem de um registro, como o Docker Hub. É a saída para build pesado: a imagem é montada fora da VPS, numa esteira de CI, e a VPS só roda.
Informe a imagem e a versão
No painel:
No ambiente do projeto, clique em New Resource e escolha Docker Image.
- 1Image name: O endereço da imagem no registro, como
registry.example.com/minha-empresa/loja. - 2Tag: A versão da imagem, como
1.4.2. Em branco, o Coolify usalatest.Use a tag ou o SHA256 digest, nunca os dois. - 3Create Application: Cria a aplicação. A porta padrão é
80: troque se a imagem escuta em outra.
- 1Image name: O endereço da imagem no registro, como
Como saber se deu certo
A aplicação usa o build pack certo para o projeto, a porta do Coolify bate com a da aplicação e o deploy termina como Finished.
Problemas comuns
O Railpack não reconhece o projeto
- Causa provável
- A pasta da aplicação está errada ou a linguagem não é detectada.
- O que fazer
- Confira Base directory. Se a detecção continuar falhando, escreva um Dockerfile no repositório e troque o build pack para Dockerfile.
Erro 502 ou No available server depois de trocar o build pack
- Causa provável
- A porta mudou: Static e Docker Image usam 80, as aplicações Git usam 3000 e o Dockerfile usa a do EXPOSE.
- O que fazer
- Ajuste a porta na página da aplicação e clique em Redeploy. Veja problemas comuns.
O servidor fica lento ou cai durante o build
- Causa provável
- O build usa mais memória do que a VPS tem livre.
- O que fazer
- Monte a imagem fora, por exemplo no GitHub Actions, e publique com Docker Image. Veja o consumo em logs e monitoramento.
Não resolveu? Veja os problemas comuns do Coolify ou abra um chamado na central do cliente.
Fontes e documentação oficial
Coolify é um software de código aberto mantido pelo próprio projeto. Este manual é da Hospedagem Segura, para quem roda o Coolify nas nossas VPS, e foi conferido na versão 4.7.5.
Continue aprendendo
- Publicar aplicaçõesComo publicar uma aplicação pelo Git no CoolifyDo endereço do repositório à aplicação no ar: build automático com o Railpack, o log do deploy e o endereço provisório.Iniciante
- Publicar aplicaçõesComo publicar um repositório privado no CoolifyDois caminhos para o Coolify ler um repositório privado: o GitHub App, com deploy automático, e a deploy key, uma chave SSH só de leitura.Intermediário
- Publicar aplicaçõesVariáveis de ambiente no Coolify: como criar e protegerConfiguração e segredos fora do código: a janela de variável, build time e runtime, a Developer View, as variáveis compartilhadas e o Redeploy.Intermediário
Rode o Coolify numa VPS da Hospedagem Segura
VPS Linux com acesso root, disco NVMe e IPv4 dedicado a partir de R$ 69,90/mês. Prefere a VPS pronta? No VPS Assistido, o Coolify vem instalado, com o painel no seu domínio, e a equipe ajuda no dia a dia.