n8n ou Make: Qual Escolher para Automatizar a Sua Empresa
Cobrança por operação contra por execução, dados que saem ou ficam, e quem mantém isto daqui a seis meses. As perguntas que decidem, sem preços que envelhecem.
1. A pergunta que toda a gente faz, e a que devia fazer
"Qual é melhor, n8n ou Make?" não tem resposta, porque resolvem o mesmo problema a partir de sítios opostos. O **Make** é um serviço alojado. Abres uma conta, ligas as tuas aplicações e constróis o fluxo num quadro visual. Não há servidor, não há actualizações, não há nada para manter. Pagas por operações executadas. O **n8n** é software que também podes alojar tu. Há versão em nuvem paga, mas o que o distingue é poderes correr a versão comunitária no teu próprio servidor, sem limite de execuções e com os dados a nunca saírem da tua infraestrutura. A pergunta útil é outra: **o que é que te custa mais — a fatura mensal ou as horas de manutenção?** Se é a fatura e tens com que gerir um servidor, o n8n alojado por ti ganha por margem larga. Se são as horas, o Make. O resto deste artigo é o detalhe que sustenta essa decisão.
2. Como cada um cobra, e porque isso muda tudo
Esta é a diferença com mais consequências práticas. O **Make** cobra por **operação**. Cada passo executado num cenário conta: ler um email é uma operação, filtrar é outra, escrever na folha é outra. Um fluxo com dez passos que corre cem vezes por dia consome mil operações diárias. Quem desenha sem contar operações descobre o custo na primeira fatura. O **n8n em nuvem** cobra por **execução** — uma execução é o fluxo inteiro, independentemente de ter três passos ou trinta. Para fluxos longos a diferença é enorme. O **n8n alojado por ti** não tem contagem nenhuma. Pagas o servidor e executas o que quiseres. Não te dou preços: mudam, e as duas empresas reestruturaram planos mais do que uma vez. Consulta as tabelas oficiais no dia em que decidires. O que não muda é o **modelo**, e é o modelo que decide se o teu caso sai caro ou barato. Faz a conta antes: quantos passos tem o fluxo típico, quantas vezes corre por dia, e multiplica. É meia hora que evita uma surpresa.
3. Comparação por critério
A tabela compara o que se mantém estável. Números de integrações e preços ficam de fora por envelhecerem de mês para mês.
| Critério | Make | n8n (nuvem) | n8n (alojado por si) |
|---|---|---|---|
| Unidade de cobrança | Por operação | Por execução | Nenhuma |
| Manutenção | Nenhuma | Nenhuma | Servidor é seu |
| Código dentro do fluxo | Limitado | JavaScript e Python | JavaScript e Python |
| Onde os dados passam | Servidores do fornecedor | Servidores do fornecedor | Só pela sua máquina |
| Integrações prontas | Muito amplas | Amplas | Amplas |
| Ligar a API sem integração | Módulo HTTP | Nó HTTP | Nó HTTP |
| Curva de aprendizagem | Mais suave | Média | Média, mais servidor |
| Controlo de versões | Limitado | Exportação JSON | JSON em Git |
4. Quando o Make é a escolha certa
**Quando ninguém na equipa programa.** O editor do Make é mais acessível, a biblioteca de integrações prontas é maior, e uma pessoa não técnica consegue alterar um fluxo sem partir nada. **Quando precisas de estar a correr hoje.** Não há servidor para provisionar, nem certificado, nem cópias de segurança. Abres a conta e começas. **Quando a integração que precisas já lá está.** Se o Make tem um módulo pronto para a aplicação de nicho que usas, isso poupa-te horas — e provavelmente não existe em mais lado nenhum. **Quando o volume é baixo.** Com poucas execuções por dia, o plano de entrada custa menos do que qualquer VPS, e não gastas tempo nenhum em manutenção. Não há nada de errado em pagar para não gerir infraestrutura. É uma troca legítima, e para muitos negócios é a correcta.
5. Quando o n8n é a escolha certa
**Quando os fluxos são longos.** Cobrar por operação penaliza exactamente o tipo de automação que poupa mais trabalho. Um fluxo de trinta passos custa trinta vezes mais no Make e o mesmo que um de três no n8n. **Quando os dados não podem sair.** Alojado por ti, nada passa por servidores de terceiros. Se processas dados de clientes, contratos ou registos internos, isto deixa de ser preferência e passa a requisito — e simplifica bastante a conversa sobre RGPD. **Quando precisas de código no meio.** O n8n deixa-te escrever JavaScript ou Python dentro do fluxo. Transformações que no Make exigiriam encadear módulos resolvem-se em dez linhas. **Quando o volume é alto e constante.** A partir de certo ponto, um VPS de poucos euros corre o que custaria muito mais em operações. **Quando queres os fluxos em Git.** Exportas em JSON, versionas, revês em pull request. Para quem trata automação como software, isto muda a forma de trabalhar. O custo é real: actualizações, cópias de segurança, monitorização e tempo de indisponibilidade passam a ser teus.
6. Instalar o n8n para experimentar
Antes de decidir, corre-o localmente meia hora. Com Docker é imediato, e experimentar responde melhor do que qualquer comparativo. Para produção acrescenta um proxy inverso com TLS, uma base de dados PostgreSQL em vez de SQLite, e cópias de segurança do volume — o mesmo padrão descrito no artigo sobre correr modelos em VPS próprio.
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=automacao.seudominio.pt
- WEBHOOK_URL=https://automacao.seudominio.pt/
# Sem isto, qualquer pessoa que alcance a porta entra.
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
- GENERIC_TIMEZONE=Europe/Lisbon
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:7. Erros que custam caro nos dois
**Não tratar as falhas.** Um fluxo sem tratamento de erro falha em silêncio, e só descobres quando um cliente pergunta pelo que nunca chegou. Põe notificação de falha desde o primeiro dia. **Sondar em vez de ouvir.** Verificar uma caixa de correio de cinco em cinco minutos gasta execuções o dia inteiro para nada. Se a aplicação suporta webhooks, usa-os: reagem em tempo real e não consomem nada enquanto não há trabalho. **Guardar credenciais dentro do fluxo.** Chaves de API coladas em nós acabam em exportações e capturas de ecrã. Ambos têm gestão de credenciais própria. **Automatizar um processo que ninguém definiu.** Automatizar confusão dá confusão mais rápida. Escreve os passos em papel primeiro; metade das vezes descobres que o processo em si é que estava errado. **Não testar com dados reais.** Fluxos que funcionam com o exemplo perfeito partem-se no primeiro campo vazio ou acento inesperado.
8. Mudar de um para o outro
Não há importação automática. Os formatos são incompatíveis e a migração é reconstrução manual. Na prática a migração é menos má do que parece, porque os fluxos raramente sobrevivem intactos: quando reconstróis, percebes passos que já não fazem falta. Mas conta com o tempo. O que reduz o custo de mudar mais tarde: documentar o que cada fluxo faz e porquê, manter a lógica de negócio fora da ferramenta sempre que possível — numa API tua que ambas chamam — e evitar depender de funcionalidades que só uma delas tem. Se estás a começar e não tens a certeza, começa pelo Make. É mais rápido a validar se o processo vale a pena automatizar. Se depois o volume ou o custo justificarem, migras já a saber exactamente o que precisas.
9. Como decidir em vinte minutos
Responde a quatro perguntas por escrito. **Quem vai manter isto daqui a seis meses?** Se não for alguém que programe, Make. **Os dados que passam no fluxo são sensíveis?** Se sim, e se isso te obriga a justificar onde são processados, n8n alojado por ti. **Quantos passos tem o fluxo típico e quantas vezes corre por dia?** Multiplica. Se der milhares de operações diárias, o modelo do Make vai doer. **Tens onde alojar e quem mantenha um servidor?** Se não, o n8n alojado por ti não é opção, por muito atraente que o custo pareça. Na maioria dos casos as respostas convergem. Quando não convergem, começa pelo Make, valida que o processo vale a pena, e migra quando o custo justificar.
Perguntas Frequentes (FAQ)
O n8n é gratuito?
A versão comunitária é gratuita para alojares tu, sob uma licença de código aberto com restrições de uso — lê-a antes de a integrares num produto que revendes. A versão em nuvem é paga. "Gratuito" significa sem taxa de licença, não sem custo: o servidor e a manutenção são teus.
Posso usar os dois ao mesmo tempo?
Podes, e às vezes faz sentido: Make para o que precisa de integrações prontas com aplicações de nicho, n8n para o que é volumoso ou toca dados sensíveis. O custo é manter duas ferramentas e saber sempre onde está cada fluxo.
Qual deles liga melhor a modelos de linguagem?
Ambos ligam às APIs habituais e ambos chamam qualquer API por HTTP. A diferença prática é o n8n deixar escrever código no meio, o que ajuda quando é preciso tratar a resposta do modelo antes de a usar.
Preciso de saber programar para usar o n8n?
Para fluxos simples, não — o editor é visual. Mas a curva é mais inclinada que a do Make, e alojá-lo exige à-vontade com Docker, DNS e certificados. Sem isso, a versão em nuvem ou o Make poupam-te frustração.
O que acontece se o meu servidor n8n cair?
Os fluxos param e os webhooks recebidos nesse período perdem-se, salvo se quem os envia repetir. É a contrapartida de alojar: a disponibilidade passa a ser tua. Monitorização e alerta deixam de ser opcionais.