n8n é melhor que Zapier ou Make?

Para empresa com volume alto, geralmente sim, porque é auto-hospedado e não cobra por execução. Zapier e Make ganham em facilidade inicial e em quantidade de conectores prontos. A conta muda de figura a partir de alguns milhares de execuções por mês.

Quando devo trocar o n8n por código?

Quando o fluxo passa de algumas dezenas de nós, quando a lógica condicional fica difícil de ler na tela, quando você precisa de testes automatizados ou quando a automação virou parte crítica da operação e não pode falhar em silêncio.

Dá para usar n8n em produção de verdade?

Dá, desde que com fila persistente, banco externo, backup dos fluxos versionado, monitoramento e credenciais fora dos nós. n8n auto-hospedado sem essa infraestrutura é protótipo rodando em produção.

n8n vale a pena? Quando usar no-code de automação

O n8n vale a pena quando o problema é conectar sistemas com regra simples e ciclo de mudança rápido, e ele tem uma vantagem concreta sobre Zapier e Make: roda no seu servidor, sem cobrança por execução. Ele deixa de valer quando o fluxo cresce em lógica, quando precisa de teste automatizado ou quando vira infraestrutura crítica. A pergunta útil não é "n8n ou código", é "esse fluxo específico vai crescer em lógica ou só em volume".

Onde o n8n é a escolha certa

Integração ponto a ponto entre serviços com API. Formulário do site vira lead no CRM, que dispara mensagem no Slack e cria tarefa. Regra linear, poucos desvios, mudança frequente. É o caso de uso ideal.

Prototipagem de processo. Antes de investir num sistema, montar o fluxo em n8n mostra em dias se a ideia funciona. Muita automação descoberta assim nunca precisa virar código, resolve e fica.

Automação de área específica que muda toda semana. Marketing e comercial mudam campanha, canal e critério constantemente. Fila de deploy para cada ajuste é atrito desnecessário.

Volume alto com lógica baixa. É aqui que o auto-hospedado se paga. Plataformas por execução ficam caras rápido; um n8n num servidor modesto processa muito mais pelo mesmo custo fixo.

Comparação honesta entre as opções

Critério	n8n auto-hospedado	Zapier / Make	Código próprio
Custo por execução	Fixo (servidor)	Cresce com volume	Fixo (servidor)
Tempo até o primeiro fluxo	Horas	Minutos	Dias
Conectores prontos	Muitos	Mais	Nenhum
Lógica complexa	Difícil de ler	Muito difícil	Natural
Versionamento e revisão	Exportando JSON	Limitado	Nativo com Git
Teste automatizado	Praticamente ausente	Ausente	Padrão
Dado sensível fora da empresa	Não sai	Sai	Não sai
Quem consegue manter	Time técnico ou analista	Qualquer pessoa	Só dev
Depuração de falha antiga	Razoável	Limitada	Completa

A linha do dado sensível costuma decidir sozinha em setores regulados: se a informação não pode trafegar por serviço de terceiro, sobram n8n auto-hospedado e código.

Os limites reais do no-code

A tela vira ilegível. Um fluxo com 15 nós é claro. Com 60, ninguém entende o que acontece sem seguir a linha com o dedo. Fluxo grande em canvas é o equivalente visual de uma função de 800 linhas.

Não existe teste de verdade. Você pode executar o fluxo manualmente, mas não há suíte que rode antes de publicar e avise que a mudança no nó 12 quebrou o caminho de exceção. Em automação crítica, isso é caro.

Versionamento é remendo. Dá para exportar JSON e versionar no Git, mas revisar diff de JSON de canvas é sofrível. Duas pessoas editando o mesmo fluxo é receita para sobrescrita.

Depuração de fluxo antigo dói. Descobrir por que uma execução de três semanas atrás falhou depende do histórico estar configurado e retido, e o histórico completo pesa no banco.

Lógica condicional profunda não cabe. Cinco caminhos aninhados com tratamento de erro em cada um: em código são 40 linhas legíveis; em canvas são 30 nós e um mapa mental.

O nó de código vira o próprio fluxo. Sintoma clássico: o time começa a resolver tudo dentro de nós de JavaScript. Se a maior parte da lógica está nesses nós, você já está escrevendo código, só que sem teste, sem versionamento e dentro de um editor ruim.

Como saber que passou da hora de migrar

Sinais concretos de que o fluxo deveria virar código:

Mais de 40 nós num único fluxo
A maior parte da lógica vive em nós de código
Ninguém sabe explicar o fluxo sem abrir a tela
A automação parou e a operação parou junto, virou infraestrutura crítica
Precisa de transação, várias gravações que têm que acontecer todas ou nenhuma
Precisa reprocessar histórico, rodar de novo os últimos três meses
Duas pessoas precisam mexer no mesmo fluxo com frequência

Migrar não é jogar fora. O fluxo visual serviu como especificação executável: ele documenta exatamente o que o processo faz, com todos os casos que apareceram na prática. Reescrever a partir dele é muito mais rápido do que partir do zero.

Se for usar n8n em produção, faça o mínimo

n8n auto-hospedado sem preparo é protótipo com endereço público. O mínimo para produção:

Banco externo (PostgreSQL), nunca o SQLite padrão
Modo fila com Redis, para não perder execução quando o processo reinicia
Credenciais no cofre da ferramenta, nunca escritas dentro dos nós
Backup versionado dos fluxos exportados, automatizado
Alerta de falha para um canal que alguém lê, e-mail ninguém lê
Política de retenção de execuções, senão o banco cresce até travar
Fluxo de dead letter: o que falhou N vezes vai para uma fila visível, não some
Ambiente separado para testar antes de publicar

Sem os itens 5 e 7, você tem uma automação que quebra sem avisar, o pior tipo, porque o problema só aparece quando alguém percebe que os dados estão errados há duas semanas.

A decisão em uma frase

Use n8n quando o custo de errar é baixo e a velocidade de mudar é alta. Use código quando o custo de errar é alto e a lógica é densa. E aceite a arquitetura mista, que é a mais comum nas empresas que fazem isso bem: o núcleo crítico em código com teste e monitoramento, e as bordas, notificação, sincronização leve, integração de marketing, em fluxo visual, onde a área consegue ajustar sozinha sem abrir chamado.