n8n self hosted: como instalar, fazer backup e proteger
Checklist para rodar o n8n em servidor próprio: instalação com Docker, PostgreSQL, chave de criptografia, backup, atualizações e webhooks seguros.
Quer aplicar isso na sua empresa?
Agendar conversa com o Juan →n8n self hosted: como instalar, fazer backup e proteger
Para instalar o n8n em servidor próprio, o caminho mais comum é usar Docker Compose em uma máquina Linux, com PostgreSQL no lugar do banco padrão, um proxy reverso com HTTPS na frente e a chave de criptografia guardada fora do servidor. A instalação em si é rápida. O que separa um teste de uma operação confiável é ter backup que restaura, acesso controlado e webhooks expostos com critério.
Principais pontos
- Use PostgreSQL desde o início em produção e trave a versão da imagem do n8n, em vez de depender da tag mais recente.
- A chave de criptografia do n8n protege as credenciais salvas. Sem ela, um backup do banco não devolve seus acessos.
- Backup só vale depois de um teste de restauração em outra máquina, com banco, chave e configuração.
- Atualize em um ambiente de teste com cópia dos fluxos antes de tocar na produção.
- Exponha para a internet apenas o que precisa: a interface do editor fica restrita, e os webhooks de produção ganham autenticação e validação.
O que decidir antes de instalar o n8n em servidor próprio?
Antes de abrir o terminal, responda a quatro perguntas. Elas evitam retrabalho depois.
- Quem é o responsável pelo servidor? Alguém precisa cuidar de atualização do sistema, disco, certificado e backup. Se ninguém tem essa função, considere um serviço gerenciado.
- Que dados passam pelos fluxos? Se há dados pessoais de clientes, a LGPD se aplica ao servidor, aos logs e às cópias de segurança. A ANPD é a referência oficial para acompanhar orientações.
- Onde o servidor fica? Servidor fora do Brasil pode caracterizar transferência internacional de dados. Vale ler antes o texto sobre transferência internacional de dados com IA e LGPD.
- A licença atende ao seu uso? O n8n usa uma licença própria, com regras sobre uso comercial. Leia os termos na documentação oficial e confirme se o seu caso se enquadra, principalmente se for oferecer o n8n a terceiros.
Também ajuda separar o que é documentação oficial do que é experiência de implantação. Os nomes de variáveis e os caminhos de configuração mudam entre versões, então confirme tudo na documentação de hospedagem do n8n antes de aplicar.
Como instalar o n8n com Docker Compose e PostgreSQL
O plano abaixo descreve a ordem das decisões, não um comando para copiar. Os detalhes exatos de cada arquivo estão na documentação oficial.
- Prepare uma VM Linux com disco separado para dados, firewall ativo e acesso por chave SSH, sem senha.
- Instale Docker e Docker Compose pelos repositórios oficiais.
- Suba dois serviços: o n8n e o PostgreSQL, cada um com volume persistente. Sem volume, os dados somem quando o contêiner é recriado.
- Configure o n8n para usar o PostgreSQL (a variável de tipo de banco aponta para postgresdb) com usuário próprio e senha longa.
- Defina a chave de criptografia (N8N_ENCRYPTION_KEY) manualmente e guarde uma cópia em um cofre de senhas. Não deixe o n8n gerar sozinho e ficar apenas dentro do volume.
- Informe a URL pública (WEBHOOK_URL) e o domínio, para que os endereços de webhook gerados estejam corretos.
- Coloque um proxy reverso com HTTPS na frente (Nginx, Caddy ou Traefik). O n8n não deve receber tráfego direto da internet sem TLS.
- Fixe a versão da imagem do n8n e registre qual está rodando.
- Crie o usuário dono da instância, ative autenticação em dois fatores quando disponível e desative cadastros que você não precisa.
O banco padrão leve serve para experimentos, mas em produção o PostgreSQL facilita backup, monitoramento e crescimento. Se o volume de execuções aumentar, a documentação descreve o modo de fila com workers e Redis. Não comece por ele sem necessidade: mais peças significam mais coisas para manter.
Por fim, configure a limpeza automática do histórico de execuções (variáveis de prune de execuções). Sem isso, o banco cresce com dados de clientes que passaram pelos fluxos, o que pesa tanto em disco quanto em privacidade.
Onde ficam as credenciais e por que a chave de criptografia importa?
O n8n guarda no banco as credenciais que você cadastra (tokens de API, senhas, acessos OAuth), criptografadas com a chave de criptografia da instância. Isso traz duas consequências práticas.
Primeiro, se você perder a chave, o backup do banco restaura os fluxos, mas as credenciais ficam ilegíveis e será preciso recadastrar tudo. Segundo, quem tem o banco e a chave juntos tem acesso a todos os sistemas conectados. Por isso, guarde a chave em local diferente do backup do banco.
Boas práticas simples para credenciais:
- Use contas de serviço ou tokens com permissão mínima, nunca o usuário de um administrador.
- Prefira um acesso por sistema, para poder revogar um sem derrubar os outros. O princípio de menor privilégio está descrito no guia de autorização da OWASP.
- Tenha uma lista de quais credenciais existem, quem criou e qual fluxo usa cada uma.
- Troque os acessos quando alguém sair da equipe.
- Não coloque segredos dentro de nós de código nem em campos de texto dos fluxos.
Se os fluxos incluem um agente de IA com acesso a ferramentas, vale limitar o que ele pode fazer e quantos passos pode dar. O texto sobre limites de passos em agentes de IA mostra como evitar execuções descontroladas.
Como fazer um backup do n8n que realmente restaura?
Um backup completo do n8n tem quatro partes. Falta de qualquer uma delas costuma ser descoberta no pior momento.
- O banco PostgreSQL, com dump periódico e cópia enviada para fora do servidor.
- A chave de criptografia, guardada separadamente em cofre de senhas.
- Os arquivos de configuração: o Compose, as variáveis de ambiente e a configuração do proxy.
- Uma exportação dos fluxos e credenciais pelo CLI do n8n, ou em um repositório de versionamento, como camada extra e legível.
Defina com o dono do processo quanto tempo a empresa aguenta sem o fluxo (tempo de recuperação) e quanto de dados pode perder (intervalo entre backups). Essas duas respostas definem a frequência e o local da cópia, e não o contrário.
O passo que quase ninguém faz: restaurar. Reserve um momento para subir uma instância limpa em outra máquina, importar o banco, informar a chave e conferir se os fluxos abrem e as credenciais funcionam. Anote o tempo que levou e os problemas encontrados. Repita depois de qualquer mudança grande na infraestrutura.
Sobre LGPD, lembre que o backup também contém dados pessoais. Ele precisa ter acesso restrito, criptografia em repouso e um prazo de retenção definido.
Como atualizar o n8n sem quebrar fluxos?
Atualizar é necessário porque correções de segurança chegam em versões novas. Mas uma atualização feita às pressas pode alterar o comportamento de um nó e parar uma rotina importante. O processo abaixo reduz o risco.
- Leia as notas de versão e procure mudanças que quebram compatibilidade.
- Faça um backup completo e confirme que ele terminou.
- Suba uma cópia de teste com o banco restaurado e a versão nova.
- Execute manualmente os fluxos críticos e compare com o resultado esperado.
- Atualize a produção em horário de baixo movimento e mantenha a versão anterior pronta para voltar.
- Registre a data, a versão e o resultado.
O mesmo vale para o sistema operacional, o Docker, o PostgreSQL e o proxy. Um calendário simples de manutenção, com responsável definido, evita que o servidor fique parado em uma versão antiga por anos.
Como controlar o acesso e a exposição de webhooks?
O n8n tem duas superfícies diferentes, e elas merecem tratamentos diferentes.
A primeira é o editor, onde se criam fluxos e se veem credenciais e execuções. Ele não deve ficar aberto para qualquer pessoa na internet. Opções comuns: restringir por VPN, por lista de IPs permitidos ou por um provedor de acesso com login corporativo na frente do proxy. Use contas individuais, nunca uma conta compartilhada, para que o histórico mostre quem mudou o quê.
A segunda são os webhooks de produção, que precisam ser alcançáveis por serviços externos, como um provedor de pagamento ou a API do WhatsApp. Aqui o objetivo é expor o mínimo.
- Separe os caminhos: o proxy deve encaminhar apenas as rotas de webhook, e não o editor.
- Exija autenticação no nó de webhook (por exemplo, um cabeçalho com segredo) sempre que o remetente permitir.
- Valide a assinatura quando o provedor oferece esse recurso. A documentação de webhooks da Stripe é um bom exemplo do padrão: verificar a assinatura, rejeitar o que não confere e tratar entregas repetidas.
- Pense em idempotência: o mesmo evento pode chegar duas vezes, e o fluxo não deve cobrar ou enviar mensagem em dobro.
- Aplique limite de requisições no proxy e registre as chamadas recusadas.
- Não coloque dados sensíveis na URL do webhook, porque URLs aparecem em logs.
Se o fluxo recebe mensagens de clientes pelo WhatsApp, o cuidado se amplia: confira o guia de integração de IA no WhatsApp da empresa para entender o que a plataforma exige antes de ligar o fluxo ao número.
Por fim, observe o que acontece. Alertas para falha de execução, disco cheio e certificado perto de vencer custam pouco e evitam surpresas. Os conceitos de logs, métricas e rastros estão resumidos no primer de observabilidade do OpenTelemetry.
Como aplicar mapear, limitar, pilotar e transferir ao n8n
O método que usamos para automação com IA funciona bem para infraestrutura também. Mapear: listar os fluxos que existem ou serão criados, os dados que passam por eles e os sistemas conectados. Limitar: dar a cada fluxo só as credenciais e permissões de que precisa, e expor só os webhooks necessários. Pilotar: começar com um fluxo real, com logs e um critério de sucesso combinado, antes de migrar o restante. Transferir: entregar à equipe um manual curto de backup, restauração e atualização, e decidir em conjunto se expande, ajusta ou para.
Cenário ilustrativo: uma empresa de serviços quer que o n8n receba pedidos de orçamento por um formulário e os registre em uma planilha, avisando o comercial. Em vez de migrar tudo de uma vez, ela instala o n8n com PostgreSQL, liga apenas esse fluxo, expõe somente o webhook do formulário com um cabeçalho secreto e deixa o editor acessível só pela VPN. Depois de algumas semanas, faz um teste de restauração em outra máquina e só então decide levar o segundo fluxo. Para quem prefere não operar o servidor, a operação gerenciada pode ser feita por meio da Be Human.
Checklist final antes de colocar em produção
- PostgreSQL em uso, com volume persistente e senha forte.
- Versão da imagem fixada e registrada.
- Chave de criptografia guardada fora do servidor.
- HTTPS ativo, editor restrito e contas individuais.
- Webhooks com autenticação e, quando possível, validação de assinatura.
- Backup automático, cópia externa e restauração testada.
- Limpeza do histórico de execuções configurada.
- Responsável nomeado para atualizações e alertas.
Perguntas frequentes
É seguro usar o n8n self-hosted para dados de clientes? Pode ser, desde que você controle o acesso, use HTTPS, restrinja o editor, proteja o backup e defina por quanto tempo guarda o histórico de execuções. A LGPD continua valendo para o servidor, e quem decide a finalidade do tratamento precisa documentá-la. Em caso de dúvida sobre base legal, consulte um profissional de proteção de dados.
Posso instalar o n8n sem Docker? Sim, a documentação oficial descreve outras formas de instalação. Docker Compose costuma ser preferido porque facilita fixar versões, repetir a instalação em outra máquina e restaurar o ambiente. A escolha deve considerar o que sua equipe já sabe operar.
O que acontece se eu perder a chave de criptografia do n8n? Os fluxos podem ser restaurados pelo banco, mas as credenciais salvas não serão mais legíveis, e você precisará recadastrar cada acesso. Por isso a chave deve ficar em um cofre de senhas, separada do backup do banco, e deve fazer parte do teste de restauração.
Com que frequência devo atualizar e testar o backup? Atualize quando houver correções de segurança relevantes, sempre passando antes por um ambiente de teste. Quanto ao backup, a frequência vem de quanto dado a empresa aceita perder, e a restauração deve ser testada de tempos em tempos e após mudanças grandes na infraestrutura.