- Este texto é um checklist que documenta em detalhes, passo a passo, o processo de auto-hospedagem em VPS usando Hetzner e Coolify
- A Hetzner é recomendada por sua baixa latência na Europa, excelente custo-benefício e planos de cobrança transparentes
- Inclui questões comuns do dia a dia, como configuração inicial do servidor com foco em segurança, segurança de SSH, firewall e configuração de atualizações automáticas
- Também orienta em detalhes sobre configuração de ambiente de produção, monitoramento, backup e solução de problemas para implantar apps Node.js com segurança
- É um guia prático para desenvolver habilidades de DevOps e capacidade de gerenciamento autônomo ao montar seu próprio servidor
Checklist de preparação para setup de VPS
- Na etapa de escolha do provedor de VPS, a Hetzner é mencionada como recomendação em termos de custo/desempenho
- É necessário escolher uma configuração com pelo menos 1 GB de RAM e 20 GB de armazenamento, além de registrar o endereço IP do servidor e as informações da conta root
- Prepare um cliente SSH na máquina local e use um gerador de senhas fortes
Por que escolher esse provedor de VPS
- A Hetzner Cloud é barata, rápida e confiável na região da Europa
- Alternativas: DigitalOcean (excelente onboarding/documentação, mas com aumento de preço), AWS Lightsail (dependência da AWS e maior dificuldade para iniciantes), Linode (estável, mas menos competitiva em preço), Render/Fly.io (convenientes como PaaS, mas com mais custos e limitações)
- A Hetzner é 2 a 3 vezes mais barata para a mesma configuração, não tem cobrança opaca e se destaca pelos datacenters na Europa
Checklist de configuração inicial do servidor
Primeiro acesso e atualização do sistema
- Atualizar a lista de pacotes e fazer o upgrade do sistema
- São fornecidos comandos para verificar informações do sistema (ex.: uname -a, cat /etc/os-release)
Configuração de segurança da conta root
- É necessário definir uma senha complexa e armazená-la com segurança
- Em vez de nomes de conta convencionais como 'admin' e 'user', criar uma conta de usuário exclusiva
- Conceder permissões sudo à nova conta e verificar se foram aplicadas corretamente
Configuração de autenticação por chave SSH
- Gerar na máquina local um par de chaves Ed25519 (recomendado) ou RSA
- Adicionar a chave pública em
.ssh/authorized_keys no servidor e configurar as permissões
- Verificar se o login por chave SSH funciona corretamente (se conecta sem pedir senha)
- Desativar a autenticação por senha e, se necessário, verificar também arquivos separados do cloud-init
- Reiniciar o daemon SSH e confirmar o funcionamento correto
- Confirmar o bloqueio de acesso root remoto com a desativação do login de root
Checklist de configuração de firewall
Configuração básica do UFW
- Negar por padrão todas as conexões de entrada e permitir as de saída
- Liberar as portas de SSH, HTTP (80) e HTTPS (443) e verificar se o UFW foi aplicado
- Opcional: restringir a porta SSH a um IP específico e alterar o número da porta (com objetivo de reforçar a segurança), criando uma camada extra de defesa
Checklist de configuração de atualizações automáticas
Configuração do Unattended Upgrades
- Instalar os pacotes unattended-upgrades e apt-listchanges, escolhendo o uso padrão
- É possível descomentar os itens de atualização de segurança e configurar alertas por e-mail e reinicialização automática
- Testar o funcionamento das atualizações automáticas e verificar o status
Checklist de implantação de aplicação em produção
Configuração do ambiente de execução Node.js
- Instalar a versão LTS do Node.js e verificar a versão
- Enviar os arquivos da aplicação para o servidor e preparar o ambiente de produção com a instalação das dependências
Uso do gerenciador de processos (PM2)
- Executar o app em modo production com o PM2, com opção de clustering
- Configurar inicialização automática do PM2 no boot e fornecer comandos de reinício/monitoramento
Configuração de Reverse Proxy (Nginx)
- Criar o arquivo de configuração do site no Nginx e aplicar o proxy pass
- Ativar o site e reiniciar o Nginx
Checklist de configuração de certificado SSL
Let's Encrypt e Certbot
- Após instalar certbot e python3-certbot-nginx, emitir automaticamente um certificado SSL baseado em domínio
- Opções de automação de renovação e teste de validade do certificado
Checklist de monitoramento e manutenção
Métodos básicos de monitoramento
- Instalar ferramentas de verificação de recursos do sistema como htop e iotop
- Monitorar em tempo real logs como syslog e auth.log, e configurar política de rotação de logs (logrotate)
Estratégia de backup
- Escrever um script de backup da aplicação e do banco de dados usando tar
- Executar backups periódicos de acordo com um agendamento (crontab)
Checklist de solução de problemas
Problemas de conexão SSH
- Verificar configuração do firewall, status do serviço SSH, logs de autenticação e rede
Erros relacionados a permissões
- Conferir permissões de arquivos/pastas, grupos e configuração do sudo
Serviço não inicia
- Verificar status e logs com systemctl e journalctl, e conferir a sintaxe do arquivo de configuração
Uso excessivo de recursos
- Analisar processos/disco/rede/logs da aplicação
Checklist de validação final
Verificação de segurança
- Revisar se todos os itens estão funcionando: autenticação por chave SSH, login por senha, login de root, firewall, atualizações automáticas, modo de produção, SSL, backup etc.
Teste de desempenho
- Fazer teste de carga com Apache Bench e monitorar recursos, verificando erros nos logs
Lista rápida de comandos de referência
Verificação de informações do sistema
- htop, df -h, free -h, uname -a
Gerenciamento de processos
- pm2 status, pm2 restart all, pm2 logs, pm2 monit
Segurança
- sudo ufw status, sudo fail2ban-client status, sudo lynis audit system
Gerenciamento de serviços
- sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx
Encerramento
- Este checklist fornece um procedimento completo de setup e gerenciamento de VPS
- Além do baixo custo, é possível obter gerenciamento direto, aprendizado e autonomia em DevOps
- A auto-hospedagem com Hetzner e Coolify permite vivenciar confiabilidade e liberdade por meio de experiência prática
- É um conteúdo que serve como guia prático para quem quer se aventurar em hospedagem VPS
1 comentários
Comentários no Hacker News
Acho que é um ótimo resumo para alguém iniciante como eu, com certeza vou favoritar.
Mas é uma pena que o título mencione Coolify e no corpo quase não fale dele.
Outro texto útil sobre um tema parecido é 'Setting up a Production-Ready VPS from Scratch', que deixei favoritado no link abaixo.
https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
Quando quero entender esse tipo de assunto mais a fundo, normalmente passo o link do texto para um LLM e uso algo como
"Este é um artigo sobre 'tema/título': https://article.link. Entenda bem e analise, depois expanda cada seção com o seu conhecimento e inclua também seções adicionais relevantes"
para estudar.
https://www.youtube.com/watch?v=taJlPG82Ucw
Estou rodando com essa configuração há cerca de 1 ano, e foi a primeira vez que senti confiança com self-hosting.
A OVH também é tão confiável quanto a Hetzner, e agora tem ofertas bem mais baratas.
https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
Se eu fosse usar Coolify, ficaria na dúvida sobre qual distribuição escolher.
Estou em dúvida entre Ubuntu 24.04 e Debian 13.
OVH VPS - 24 vCPU (ou threads), 96 GB de RAM por US$ 53,4/mês.
Hetzner VPS (considerando a opção AMD): 16 vCPU, 32 GB, US$ 54,9/mês.
DO Droplet: 16 vCPU, 64 GB de RAM por US$ 504/mês.
Linode e Upcloud também ficam muito mais caros que a OVH, com 24~20 vCPU e 96 GB de RAM por US$ 576/mês.
Não sei qual CPU a OVH usa, mas mesmo considerando a diferença de preço, mesmo que seja uma CPU Intel E-Core, ainda assim parece um bom negócio.
Só para constar, a Hetzner também tem opções Intel vCPU mais baratas, mas são em hardware antigo e as vagas só abrem quando outro cliente cancela.
Por isso comparei apenas com a opção AMD mais nova.
O único problema da OVH é que, para alugar um VPS (na faixa de US$ 30/mês), eu precisei enviar uma cópia do meu documento de identidade.
Não queria espalhar meus dados pessoais desse jeito, então acabei escolhendo um provedor mais caro.
Pela minha experiência (que não é tão longa assim), os servidores cloud da Hetzner tiveram desempenho bem melhor que o VPS da OVH.
Estou satisfeito com as duas.
Fico curioso sobre por que OVH e Hetzner são tão baratas em comparação com outros provedores.
Até entendo um pouco no caso de VPS, já que deve haver mais compartilhamento que em outros lugares, mas essas duas também têm servidores dedicados muito baratos.
Chega a dar a impressão de algum tipo de isca, e também fico me perguntando se os preços da OVH mudaram recentemente.
Lembro que, há alguns anos, ela era mais cara que a Hetzner.
Todas as CPUs mencionadas aqui provavelmente são, na prática, recursos compartilhados.
E elas não divulgam o quanto esse compartilhamento realmente acontece.
Na Hetzner existem servidores com a mesma quantidade de núcleos custando metade do preço.
Isso não aparece claramente na superfície, mas se você testar o desempenho por conta própria, os servidores mais baratos na prática entregam metade da performance.
Desativei estas duas configurações de CSS e a UI/UX do blog melhorou muito.
pre {
margin: 2rem 0 !important;
padding: 1rem !important;
}
O padding e a margem dos blocos de código eram tão grandes que só dava para ver 3 linhas na tela.
E, se você instalar Webmin/Virtualmin, tarefas como adicionar novos subdomínios ou usuários ficam bem mais simples.
Cliquei porque fiquei curioso sobre o Coolify, mas na prática ele só é mencionado nas tags, na introdução e na conclusão; no corpo do texto não tem conteúdo sobre ele.
Acho inadequado o Coolify ter sido citado.
Na verdade, o texto é sobre como preparar um VPS para implantar o Coolify.
Não trata da instalação do Coolify em si.
Até hoje eu gerencio todos os meus serviços em VMs com Docker Compose, então cliquei porque queria saber se o Coolify seria uma alternativa significativamente melhor do que esse método.
Mas não havia absolutamente nenhum conteúdo real sobre o Coolify, e o trabalho manual para "prepará-lo" pareceu ainda mais complicado.
Meu jeito, em que “uso uma imagem base do Docker Compose e ajusto só algumas coisas”, pareceu muito mais simples,
então fiquei com a sensação de que o método que já uso continua valendo a pena.
Um ponto positivo é que, para migrar entre hosts, 99% do trabalho se resolve copiando um único arquivo YAML do Docker Compose.
Testei o Coolify há alguns meses e, quando vários contêineres estavam conectados via Compose, surgiram todo tipo de problema.
Por exemplo, eu esquecia que certo contêiner já estava rodando e subia outro duplicado, ou então os dois ficavam em execução mas o Coolify só reconhecia um.
Quando registrei cada serviço separadamente no Coolify, funcionou um pouco melhor.
No fim, também voltei para uma configuração independente baseada em Docker Compose, e acabou sendo muito mais fácil de operar.
Acho que tentativas como o Coolify são realmente necessárias, mas neste momento ainda está aquém do nível necessário para uso sério em produção.
Se o Coolify ou projetos parecidos não oferecerem suporte a backup de banco de dados e replicação por streaming, vão continuar só no campo do hobby.
Eu opero 2 VMs com Docker Compose e scripts bash, e só com backup por hora no S3, wal streaming e replicação por streaming de PG e Redis já considero atendido o mínimo necessário para produção real.
Vai depender do caso de uso, mas eu já usei tanto Coolify quanto CapRover.
No fim escolhi o CapRover, porque com Git Hook ele faz build automático a cada commit e consigo subir apps NodeJS mais rápido.
Os dois oferecem esse recurso, mas o CapRover tem menos atrito.
O Coolify tem mais funcionalidades.
O Coolify roda em cima de Traefik e Docker e, no fim das contas, é basicamente uma UI por cima disso.
Faltam muitos recursos essenciais relacionados a backup (embora dê para contornar com algo como restic), e a UX é apenas aceitável.
O Coolify ainda exige privilégio de root na instalação.
Ouvi dizer que estão desenvolvendo uma branch que instala sem root.
Você pode entrar no servidor por ssh, instalar o Coolify e depois desativar o login root.
Se estiver disposto a apagar o servidor e configurar tudo de novo do zero, dá para fazer assim.
Recentemente também tentei fazer um deploy com Coolify totalmente do zero, mas continuei tendo erros com chaves ssh.
Eu já implanto vários projetos normalmente em outros servidores, mas essa abordagem de “é só me dar o arquivo docker compose” nunca funcionou bem de verdade para mim.
Recentemente migrei um servidor FreeBSD para a Hetzner e foi muito fácil.
A única variável foi que as portas para servidor de e-mail ficam bloqueadas até o ciclo de cobrança terminar completamente.
Entendo essa política, mas isso não foi explicado claramente no início e me pegou de surpresa.
Só para você saber: se o cartão de crédito expirar, a Hetzner pode cortar a rede imediatamente.
Não houve aviso prévio, e só descobri depois que um cliente de verdade ou alguém da equipe entrou em contato.
Isso realmente já aconteceu comigo.
Se você explicar o tipo de tráfego para a equipe da Hetzner e perguntar, às vezes eles abrem a porta antes.
Eu mostrei evidências do projeto que estava migrando e eles liberaram na hora.
Ferramentas como o Coolify (e Dokploy etc.) também parecem boas, mas sempre me incomoda que o estado do servidor não fique registrado como código.
Por isso prefiro NixOS ou Ansible, mas para montar algo realmente de produção ainda exigem boilerplate e customização demais.
Queria saber se alguém conhece algum framework de infraestrutura como código que não seja Kubernetes, seja mais declarativo e facilite a gestão de servidores de produção.
Quase não há o que fazer backup nas configurações do Coolify, e as configurações das aplicações ficam todas em /data/coolify.
Faço backup do volume inteiro com kopia.
Não é algo particularmente elegante, é meio gambiarra, mas para recuperação de desastre é um método aproveitável.
Bom guia.
Mas especialmente ao usar a Hetzner, não concordo com a configuração de firewall.
Se você só precisa de uma configuração simples, o firewall fornecido pela própria Hetzner já é suficiente, e ainda tem a vantagem de “terceirizar” isso.
Se quiser algo mais customizado, também dá para configurar pela API.
https://docs.hetzner.cloud/reference/cloud#firewalls
Fico curioso se existe alguma desvantagem crítica no firewall da Hetzner.
Acho perigosa a recomendação de “permitir SSH apenas para o meu IP” (opcional, mas recomendado).
Se o IP mudar, você pode acabar completamente sem acesso.
Dá para resetar pelo painel da Hetzner, mas em vez de se prender a um IP residencial que vive mudando, é melhor usar algo como Tailscale
ou ter um IP fixo de uma VPN externa.
Só usar autenticação por chave no SSH já evita quase todos os problemas de segurança.
Também é bom adicionar uma camada extra para reduzir ruído nos logs e, se houver serviços que não precisam ficar expostos externamente além do SSH,
acho melhor protegê-los com VPN ou algo do tipo.
Na verdade, a maioria dos serviços no servidor é mais vulnerável que o SSH.
É claramente arriscado.
Muita gente em casa usa IP dinâmico.
Acho que configurar chaves SSH e apenas bloquear o login root já é seguro o suficiente.
Acho melhor substituir a parte de configuração do app de produção por Docker.
Hoje em dia o Docker é muito mais reproduzível e fácil de configurar.