Docker Compose em VPS: stack self-hosted sem Kubernetes
-
Maicon Ramos
- Docker, Docker Compose, n8n, self-hosted, VPS
- 13 minutos de leitura
Navegue por tópicos
Resposta curta: Docker Compose funciona bem para uma aplicação pequena em uma única VPS. Ele organiza serviços, redes e volumes em um arquivo. Não resolve backup externo, monitoramento ou recuperação sozinho. A escolha segura é montar uma Stack Recuperável: deploy, dados, segredos e domínio precisam voltar a funcionar em outro host.
Quando Docker Compose é a escolha certa
💡 Vai rodar n8n numa VPS? A gente comparou o preço real em cada provedor — com renovação e requisitos — em VPS para n8n.
Docker Compose define e executa aplicações com vários containers a partir de um arquivo Compose. A própria Docker documenta seu uso em produção para uma aplicação em um único servidor. Isso não equivale a alta disponibilidade. Significa que a ferramenta atende bem uma operação pequena que aceita o limite de um host.
Para o solo builder, o ganho está em trocar uma sequência de comandos soltos por uma definição versionável. Você passa a saber quais serviços existem, quais redes eles usam e onde os dados persistem. O problema é que esse YAML descreve a aplicação. Ele não faz cópia externa, não testa restauração e não decide quais portas devem ficar públicas.
| Cenário | Compose manual | Painel Docker | PaaS gerenciado |
|---|---|---|---|
| Poucos serviços em uma VPS | Bom quando você aceita SSH e Git | Bom quando uma UI reduz atrito | Pode custar mais do que o necessário |
| Atualizações e logs | Você executa e registra o processo | A UI ajuda, mas não elimina a operação | Parte da operação fica com o fornecedor |
| Backup e restore | Você define e testa | Continua sendo sua responsabilidade | Verifique cobertura, retenção e restauração |
| Quando evitar | Se ninguém consegue diagnosticar a VPS | Se o painel vira uma camada que ninguém entende | Se precisar de controle específico do host |
Use Compose quando a aplicação cabe em uma VPS, os serviços são conhecidos e existe alguém responsável por atualizar e recuperar a stack. Evite quando você precisa de múltiplos nós, tolerância a falha do host ou não consegue manter uma rotina mínima de operação. Kubernetes não é obrigatório por existir. Ele resolve um problema maior e traz uma camada maior para manter.
Se você ainda está aprendendo os conceitos básicos, veja este guia Docker no VPS para iniciantes. Aqui, o foco é a operação de uma stack que já passou da fase de testar um container isolado.
O que o Compose organiza e o que continua sendo seu problema
Um arquivo compose.yaml pode declarar serviços, redes e volumes. A vantagem é repetir o deploy com a mesma configuração. A documentação oficial do Docker Compose trata esse arquivo como a definição da aplicação multi-container.
Volumes merecem atenção especial. Um container pode ser recriado sem que um volume nomeado seja apagado. Isso é útil para bancos e uploads. Também pode criar uma falsa sensação de segurança: o dado continua na mesma VPS. Se o host for perdido, um volume local não é uma cópia externa.
A Stack Recuperável separa quatro camadas. Cada uma precisa de destino e validação próprios.
| Camada | O que guardar | Como validar | Risco se faltar |
|---|---|---|---|
| Deploy | compose.yaml e versões de imagem |
Rodar docker compose config em outro host |
Não saber o que subir |
| Banco | Dump compatível com o banco | Restaurar em ambiente separado | Dados persistentes indisponíveis |
| Volumes e uploads | Arquivos da aplicação | Recuperar permissões e conteúdo | App sobe sem arquivos ou estado |
| Segredos, DNS e infra | Valores fora do Git, domínio e acesso | Reaplicar sem expor chaves | Serviço sobe sem conseguir operar |
A Docker explica como volumes Docker persistem dados. Persistência ajuda na rotina. Backup exige outra cópia e, principalmente, um restore testado.
Compose, painel Docker ou PaaS gerenciado?
Compose manual costuma ser a melhor escolha quando você quer entender a stack e manter a definição no Git. Um painel como Portainer, Coolify, EasyPanel ou Dokploy reduz o atrito da interface. Ele não transforma uma VPS em operação gerenciada. Ainda existem DNS, dados, permissões, atualizações e incidentes.
O ponto não é declarar que uma opção vence sempre. A questão é identificar onde sua equipe perde tempo. Se publicar variáveis, ler logs e reiniciar serviços por SSH consome energia demais, um painel pode ajudar. Se o painel esconder o estado e ninguém souber reconstruir a aplicação sem ele, criou-se outra dependência.
Para comparar os painéis que ficam entre Docker puro e uma experiência mais guiada, consulte o comparativo Coolify, EasyPanel e Dokploy. A recomendação Runzos é simples: escolha a menor camada que sua operação consegue entender e recuperar.
Requisitos e custo real de uma VPS Docker
Não existe uma RAM mínima universal para Docker Compose. O consumo depende da aplicação, do banco, de builds, dos logs e da concorrência. Como referência comercial, a oferta da Servla no Runzos lista 2 vCPU, 4 GB de RAM e 30 GB NVMe por R$ 39,90 ao mês. Também lista 4 vCPU, 8 GB de RAM e 50 GB NVMe por R$ 69,90 ao mês. Valores e condições precisam ser revistos no dia da contratação.
| Cenário | Componentes | Referência editorial | Sinal de upgrade |
|---|---|---|---|
| Automação leve | App único e poucos dados | Comece pequeno e monitore | Memória, CPU ou disco pressionados |
| App com banco | Aplicação, PostgreSQL e volume | Planeje espaço para dados e cópias | Crescimento de banco e I/O |
| n8n em queue mode | Principal, workers, Redis e banco | Mais serviços e pontos de recuperação | Filas, concorrência e workers exigem revisão |
A página de oferta da Hostinger sugere 2 vCPU e 4 a 8 GB de RAM como ponto editorial para muitas aplicações pequenas e médias. Isso não é garantia de capacidade. Monitore CPU, memória, I/O e fila antes de atribuir um problema à VPS.
O preço mensal não é o custo inteiro. Domínio, object storage, e-mail, cópia externa e horas de manutenção entram na conta. Esse é o Custo do Container Parado, mas o conceito central deste guia continua sendo a Stack Recuperável: uma VPS barata deixa de ser economia quando uma falha não tem caminho de volta.
Para escolher o host com mais critério, leia como escolher VPS para apps self-hosted.
Fluxo mínimo para subir, validar e atualizar uma stack
Este fluxo assume que Docker Engine e o plugin Docker Compose já estão instalados na VPS. Ele não substitui a documentação da sua aplicação. Também não fornece um arquivo de produção pronto para copiar, porque domínio, imagem, variáveis e banco precisam ser definidos para o seu caso.
1. Separe projeto, configuração e segredos
Crie uma pasta por aplicação. Mantenha compose.yaml no Git. Não envie .env, chaves ou senhas para o repositório. Quando a aplicação suportar o recurso, use a orientação da Docker para segredos no Docker Compose. Variáveis de ambiente podem expor valores sensíveis se forem tratadas sem cuidado.
Antes de iniciar qualquer serviço, valide a estrutura que o Compose vai interpretar:
docker compose config
O comando não prova que a aplicação funcionará. Ele ajuda a encontrar erro de sintaxe, interpolação e referências antes de criar containers.
2. Suba a stack e confira o estado
Depois de revisar imagens, portas, volumes e variáveis, inicie em segundo plano:
docker compose up -d
docker compose ps
docker compose logs --tail=100
docker compose ps mostra se os serviços esperados estão em execução. Os logs ajudam a localizar falhas de conexão, migração ou variável ausente. Não encerre a validação quando o container aparece como iniciado. Confirme a rota pública da aplicação e o comportamento que importa para o usuário.
3. Exponha apenas o que precisa ser público
Publicar uma porta cria um encaminhamento entre a porta do host e a porta do container. A Docker explica como a publicação de portas funciona. Em uma stack comum, o proxy reverso recebe tráfego público. PostgreSQL e Redis não devem ser publicados na internet sem uma necessidade pública explícita.
Use uma rede interna para serviços que conversam entre si. Deixe a definição de firewall do host para uma rotina específica da sua distribuição. Docker interage com iptables e nftables. Copiar um comando de firewall sem saber como ele se comporta naquele host pode bloquear a aplicação ou expor algo por engano.
4. Atualize com versão planejada e reversão possível
Evite tratar uma tag flutuante como plano de rollback. Registre a versão de imagem que estava estável. Faça a cópia necessária antes da alteração. Em seguida, puxe e recrie os serviços:
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100
Se a validação falhar, restaure a referência de imagem conhecida no compose.yaml, aplique novamente docker compose up -d e investigue com logs. O rollback do container não recupera automaticamente dados migrados. Por isso, banco e volume precisam de plano próprio.
Troubleshooting rápido
| Sintoma | Primeiro diagnóstico | Evite |
|---|---|---|
| Container reinicia | docker compose logs --tail=100 e variáveis exigidas |
Reiniciar sem ler o erro |
| App não abre | Conferir proxy, porta pública e DNS | Expor banco para “testar” |
| Banco não conecta | Conferir rede Compose, nome do serviço e segredo | Publicar PostgreSQL sem necessidade |
| Disco enche | Conferir volumes, dados e logs | Apagar volume sem backup testado |
| Atualização quebrou | Voltar imagem versionada e checar migração | Supor que recriar container desfaz dados |
Exemplo de stack solo: n8n, banco e monitoramento
n8n é um exemplo útil porque parece simples até crescer. A documentação do n8n para Docker mantém um volume persistente para seus dados. Mesmo com PostgreSQL, o diretório n8n guarda elementos como chaves de criptografia e logs. Apagar ou trocar esse estado sem planejamento pode impedir acesso a credenciais existentes.
Uma instalação pequena pode ter n8n, banco, proxy e rotina de cópia. Não comece com Redis e workers apenas porque eles existem. O modo fila do n8n adiciona instância principal, workers, Redis e banco para escalar. Também exige que workers e webhooks compartilhem a chave de criptografia da instância principal para acessar credenciais no banco.
Cada novo serviço traz uma dependência de recuperação. É por isso que a Stack Recuperável é mais útil do que uma lista de containers “modernos”. Comece com a menor arquitetura que cumpre a carga atual. Adicione escala depois de observar filas, memória, CPU e necessidade real.
Se está escolhendo qual projeto hospedar antes de montar a infraestrutura, confira estes apps self-hosted para rodar em VPS.
Backup, migração e o Teste de Saída
Backup não é uma palavra mágica. Uma Stack Recuperável precisa de uma cópia externa e de uma evidência de que ela volta. O Teste de Saída é a prova prática: subir o deploy, dados, segredos e rota em outro host antes de um incidente real.
Faça o teste em um ambiente separado quando possível. Documente qual arquivo foi usado, qual dump foi restaurado e quais passos foram necessários. Remova IPs, tokens e domínios privados de qualquer evidência compartilhada. O objetivo não é simular alta disponibilidade. É descobrir a dependência esquecida enquanto ainda há tempo para corrigir.
A atualização também entra nesse teste. Uma imagem nova pode exigir migração de banco. Um volume pode conter mais estado do que parecia. A documentação do Compose ajuda no deploy em produção de servidor único, mas não substitui a responsabilidade operacional por cópia, verificação e recuperação.
Checklist final: use ou evite Docker Compose em VPS
Use Docker Compose se você consegue responder “sim” às perguntas abaixo:
- O projeto cabe em uma VPS e não exige tolerância à falha de múltiplos nós.
- O
compose.yamlestá versionado e passa emdocker compose config. - Banco, volumes, segredos e DNS têm dono e processo de recuperação.
- Portas públicas são limitadas ao que a aplicação realmente precisa.
- Atualizações usam versões planejadas, logs e validação pós-deploy.
- Já existe, ou está agendado, um Teste de Saída em outro host.
Evite começar com Compose manual se ninguém pode acessar, ler logs e recuperar a VPS. Nesse caso, um painel ou PaaS gerenciado pode ser uma escolha mais honesta. A ferramenta certa é a que reduz trabalho sem esconder os riscos que continuam seus.
FAQ
Docker Compose pode ser usado em produção?
Sim, a Docker documenta o uso de Compose em produção para uma aplicação em um único servidor. Isso não cria alta disponibilidade. Você continua responsável pelo host, por dados persistentes, segredos, exposição de portas e recuperação.
Docker Compose substitui Kubernetes?
Não. Compose atende uma aplicação multi-container em um host. Kubernetes trata outro escopo, com múltiplas máquinas e uma camada operacional maior. Para uma operação pequena, Kubernetes pode ser complexidade sem ganho proporcional.
Quantos GB de RAM preciso para Docker Compose em VPS?
Não há número universal. Aplicação, banco, logs, concorrência e builds mudam o consumo. Referências comerciais podem orientar um ponto inicial, mas a decisão deve acompanhar métricas de CPU, memória, disco, I/O e fila.
Volume Docker é backup?
Não. O volume persiste além do ciclo de vida do container, mas pode continuar no mesmo host. Backup exige cópia externa. Recuperação só é demonstrada depois de um restore testado.
Devo expor PostgreSQL ou Redis na internet?
Em geral, não sem uma necessidade pública explícita. A publicação de porta encaminha tráfego do host para o container. Prefira deixar banco e Redis na rede interna da stack e publique somente o ponto de entrada necessário.
Quando um painel ou PaaS gerenciado é melhor?
Quando a operação não consegue manter SSH, logs, atualizações e recuperação com segurança. Painéis reduzem atrito de interface. PaaS transfere parte da operação. Nenhuma das opções elimina a necessidade de verificar dados, retenção de backup e restauração.
Conclusão: escolha a stack que você consegue recuperar
Docker Compose é uma base direta para colocar poucos serviços em uma VPS sem transformar uma operação pequena em um cluster. O limite saudável é aceitar que o YAML não faz o trabalho invisível por você. A Stack Recuperável inclui deploy, dados, segredos, rede e um Teste de Saída.
Se a sua operação já tem esse mínimo, avalie a VPS indicada para rodar stack Docker/self-hosted. Para comparar alternativas, use também a rota interna da Hostinger VPS para n8n ou a Turbo Cloud. Revise preços, condições e cobertura de backup antes de contratar.














