Quem pesquisa sobre n8n VPS quer duas coisas ao mesmo tempo: uma conta de self-hosting barata e uma instância que não vire porta aberta na internet. A boa notícia é que dá pra unir as duas numa máquina modesta. A ruim é que o atalho de instalar e expor a porta 5678 direto no IP público é exatamente o caminho que você não deve seguir.
A receita que funciona tem quatro ingredientes: firewall fechado, Docker Compose com as variáveis de ambiente corretas, um proxy reverso cuidando do HTTPS e controle de versão na hora de atualizar. Vou montar isso passo a passo, seguindo o que a documentação oficial do n8n recomenda.
Por que n8n VPS exposto direto na porta 5678 não serve para produção
Por padrão, o n8n escuta na porta 5678 — controlada pela variável N8N_PORT — e responde em HTTP puro. Se você liberar essa porta no firewall e acessar pelo IP, o tráfego de login, credenciais e webhooks circula sem criptografia. E cada serviço exposto é mais superfície de ataque numa máquina que já tem SSH rodando.
A documentação de SSL/TLS do n8n recomenda colocar um reverse proxy — Traefik ou Caddy — na frente do n8n, em vez de passar certificados direto pra ele. O proxy termina o HTTPS e renova os certificados sozinho, o que elimina a pior tarefa recorrente de quem administra servidor. Vale lembrar o aviso que as docs repetem: self-hosting do n8n exige conhecimento técnico, e erros de configuração podem causar perda de dados e problemas de segurança. O problema não é a VPS barata; é rodar configuração de teste em cima de dados reais.
O que você precisa: VPS, domínio, Docker e a versão certa do n8n
- Uma VPS com Docker e Docker Compose instalados. Os guias oficiais para VPS, como o guia da Hetzner, seguem esse mesmo desenho; o da DigitalOcean também.
- Um domínio com registro A apontando pro IP da VPS, por exemplo n8n.seudominio.com. O HTTPS automático depende disso.
- A versão certa do n8n: a stable atual é a 2.42.6, e a beta é a 2.43.3. Pra produção, fique na stable.
Se algum detalhe do seu provedor for diferente, como a imagem do sistema ou o firewall da própria nuvem, confira na documentação oficial antes de seguir.
Passo 1: firewall com UFW liberando só 22, 80 e 443
A regra dos guias oficiais é abrir apenas as portas 80 e 443 pro acesso web ao n8n. Somando o SSH, você fica com três portas expostas, e nada mais. A 5678 não precisa aparecer no firewall porque o proxy conversa com o n8n dentro da rede interna do Docker.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw statusA porta 80 continua necessária porque os emissores de certificado a usam na validação do domínio. Se quiser apertar mais, restrinja a 22 ao seu IP fixo — SSH aberto pro mundo inteiro é convite pra robô de dicionário.
Passo 2: Docker Compose do n8n com as variáveis de ambiente corretas
O compose oficial de exemplo deixa o n8n acessível somente por HTTPS e define as variáveis-chave: N8N_HOST com o subdomínio, N8N_PROTOCOL=https e NODE_ENV=production. O trecho a seguir reproduz o serviço do n8n com a versão fixada:
services:
n8n:
image: docker.n8n.io/n8nio/n8n:2.42.6
restart: unless-stopped
environment:
- N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
- N8N_PROTOCOL=https
- NODE_ENV=production
- N8N_PROXY_HOPS=1
- N8N_WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:Três pontos de atenção. Primeiro, o volume n8n_data:/home/node/.n8n guarda workflows, credenciais e o banco interno — é dele que você tira backup. Segundo, a versão vai fixada por número exato, que é o que a docs recomenda desde o n8n 2.0. Terceiro, o arquivo completo, com o serviço do Caddy incluído, está no guia oficial de Docker Compose — copie de lá pra não divergir em nenhum detalhe.
Passo 3: proxy reverso com HTTPS automático usando Caddy (ou Traefik)
O Caddy emite e renova o certificado do seu domínio sozinho, sem cron e sem script. O guia oficial usa um Caddyfile mínimo, com reverse_proxy n8n:5678 e flush_interval -1:
n8n.seudominio.com {
reverse_proxy n8n:5678
flush_interval -1
}O reverse_proxy n8n:5678 aponta pro serviço do n8n pelo nome, dentro da rede do Docker — por isso o compose não publica a 5678 no host. O flush_interval -1 desativa o buffer de resposta, evitando que respostas em tempo real, como as do editor, fiquem presas atrás do proxy. O Caddy já repassa os headers de proxy por padrão.
Se você já tem Traefik na VPS, serve igual: as docs citam Traefik e Caddy como as duas opções pra terminar TLS na frente do n8n. Escolha um e mantenha só um.
Passo 4: webhooks atrás do proxy com N8N_WEBHOOK_URL e N8N_PROXY_HOPS
Aqui mora o erro clássico. A variável WEBHOOK_URL foi deprecada a partir do n8n 2.35.0 e substituída por N8N_WEBHOOK_URL. Se você copiou tutorial antigo, o n8n pode montar URLs de webhook apontando pro endereço errado — e nenhuma integração externa chega.
Atrás de reverse proxy, a docs manda definir N8N_PROXY_HOPS=1 quando existe um proxy no caminho, e garantir que o último proxy repasse os headers X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. Sem isso, o n8n não enxerga o endereço real com que os clientes o chamam. O exemplo completo está no guia de configuração de webhooks com reverse proxy.
No compose do Passo 2 essas variáveis já entraram, e o Caddy do Passo 3 repassa os headers por padrão. Teste com um workflow de webhook de teste chamado de fora da VPS antes de colocar coisa séria pra rodar.
Atualizações: fixar a versão no compose e acompanhar patches sem quebrar a instância
O n8n lança versão minor quase toda semana. Pra dimensionar: a release 2.43.0 saiu em 2026-10-06 trazendo o Browser Use pra todos os usuários, o patch 2.41.7 apareceu no GitHub em 2026-10-05, e a beta atual é a 2.43.3. Ritmo assim é ótimo pra correção e péssimo pra quem atualiza produção no impulso.
Desde o n8n 2.0 os canais foram renomeados de latest/next pra stable/beta, e a recomendação oficial passou a ser fixar a versão por número específico no compose, em vez de tag flutuante. Na prática: você roda na 2.42.6, lê o que mudou, e só então muda a linha do image pra nova versão:
docker compose pull
docker compose up -dAntes de atualizar, faça backup do volume n8n_data. Se a nova versão quebrar algo, o rollback é voltar a tag anterior e repetir os dois comandos. Pra acompanhar o que sai, siga a página de releases no GitHub e a página de release notes na documentação oficial. E evite a beta em produção: a própria docs avisa que pode ser instável.
Na prática: como uso isso aqui
No meu caso, a VPS é da Hostinger — uso e recomendo pela estabilidade e pelo preço. A diferença pro passo a passo acima é que eu ponho o Cloudflare na frente, usando Tunnel pra publicar a instância, então o tráfego entra por ali em vez de bater direto nas portas do servidor.
De webhook parado por causa de WEBHOOK_URL atrás de proxy eu nunca tive problema. E nos meus compose eu sempre usei a tag stable, pra trabalhar com a última versão estável, em vez de fixar número. Reconheço o trade-off: é o contrário do que a documentação recomenda. Se a sua instância é crítica, com cliente em cima, faça o que a docs manda — fixe o número e atualize devagar, com backup em mãos.
Problemas comuns e como resolver
- 502 ou 504 no navegador depois de subir o Caddy: o proxy não alcançou o n8n. Confira se o nome do serviço no compose é
n8ne se o Caddyfile aponta pran8n:5678. - Webhook montado com endereço errado: variável antiga
WEBHOOK_URLem uso. Troque porN8N_WEBHOOK_URL, que vale desde o n8n 2.35.0. - Editor lento ou travando atrás do proxy: confira o
flush_interval -1no Caddyfile, que o guia oficial usa justamente pra não segurar as respostas. - Certificado não emite: quase sempre o DNS ainda não aponta pra VPS ou a porta 80 está fechada no firewall.
- Atualização quebrou algo: volte a tag fixada anterior no compose e rode
docker compose up -dde novo. Com número fixo, rollback é uma linha.
Conclusão
VPS barata e n8n combinam bem, desde que a configuração respeite produção: firewall com 22, 80 e 443 apenas, proxy reverso com HTTPS automático, variáveis corretas pra webhook e proxy, e versão fixada no compose com atualização planejada. Nada disso é opcional quando tem credencial e histórico de execução dentro daquele volume.
Siga o guia oficial de referência na sua instalação, teste um webhook de fora antes do go-live e mantenha backup do volume. Com isso, sua instância fica mais parecida com um serviço e menos com um experimento.
Perguntas frequentes
Quais portas preciso liberar no firewall da VPS?
Apenas 22 (SSH), 80 e 443. Os guias oficiais pra VPS mandam abrir somente 80 e 443 pro acesso web ao n8n; a 5678 fica restrita à rede interna do Docker.
WEBHOOK_URL ainda funciona no n8n?
Foi deprecada a partir do n8n 2.35.0. Use N8N_WEBHOOK_URL e, atrás de proxy, defina também N8N_PROXY_HOPS=1 com os headers X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto repassados.
Qual versão do n8n devo usar em produção?
A stable atual é a 2.42.6; a 2.43.3 é beta e pode ser instável. A recomendação oficial é fixar o número exato da versão no compose e atualizar só depois de ler o que mudou.
