O que conta como ferramenta open source de automação (e o que não)
Uma ferramenta open source de automação é um motor que orquestra fluxos — dispara, liga apps, move dados, decide entre passos — e cujo código podes alojar na tua própria infraestrutura em vez da nuvem de um terceiro. A diferença face a Zapier ou Make não é o que fazem, é onde vive o motor e quem controla o dado: num SaaS fechado, nos servidores deles; numa ferramenta open source, onde tu disseres.
Vale a pena desfazer uma confusão de nome. «IA open source» costuma referir-se aos modelos de linguagem que podes auto-alojar (Llama, Mistral e companhia), e isso é outra decisão — modelo aberto vs. API fechada. Aqui falamos de orquestração: a ferramenta que executa o fluxo e chama o modelo, seja qual for. Duas camadas separadas, escolhidas por critérios diferentes.
As três que importam: n8n, Activepieces e Windmill
O panorama open source é vasto, mas para automação com IA em empresa a conversa real gira à volta de três. As três podem ser auto-alojadas; diferenciam-se na licença, na abordagem e a quem se destinam.
| Ferramenta | Licença | Abordagem | A quem encaixa |
|---|---|---|---|
| n8n | Sustainable Use License (fair-code) | Editor visual de nós + código onde for preciso | Equipas mistas; a maior comunidade e mais integrações |
| Activepieces | MIT (a mais permissiva) | No-code visual, simples | Equipas pouco técnicas que querem liberdade de licença total |
| Windmill | AGPLv3 | Code-first (TypeScript, Python, Go, Bash, SQL) com UIs auto-geradas | Equipas de engenharia que querem tooling interno como código |
A licença não é um rodapé de advogados: muda o que podes fazer. A do n8n é aberta para uso interno mas restringe revendê-lo como serviço gerido a terceiros. O Activepieces, sob MIT, não te prende a quase nada. O Windmill, sob AGPLv3, só te obriga a publicar as tuas alterações se distribuíres o software — não se o usares de portas adentro. Para 90% das empresas, que o alojam para a própria operação, as três comportam-se como open source a sério.
Quando compensa alojá-lo tu (e quando não)
O self-host não é grátis nem superior por defeito. Compensa quando uma destas pressões é real — e não compensa quando nenhuma o é.
Compensa se:
- O dado não pode sair de casa. Setor regulado, informação sensível ou uma política de RGPD que exige que o dado viva no teu perímetro. É a razão número um e a que mais pesa.
- O volume dispara o preço. Os SaaS cobram à operação ou à tarefa; a partir de certo volume, o custo por execução de um plano cloud cresce mais depressa do que o de um servidor teu.
- Precisas de lógica à medida ou código. Quando o fluxo pede algo que o no-code não cobre, poder meter código em qualquer passo deixa de ser um luxo.
- Queres evitar o lock-in. Controlar o motor significa que uma mudança de preços ou de condições do fornecedor não te encosta à parede.
Não compensa se:
- Só ligas um par de apps e o plano cloud te serve: mudar custa mais do que poupa.
- Não tens quem mantenha a infraestrutura (vê o custo real mais abaixo).
- O teu gargalo não é a execução, é o critério: ler texto livre, perceber a intenção, decidir sobre o ambíguo. Mudar de ferramenta não resolve isso; é pôr uma camada de IA por cima.
O custo real do self-host, para além da licença
«0 € de licença» é verdadeiro e enganador ao mesmo tempo. O custo não está na licença; está em operar o sistema. É isto que aparece mesmo na fatura:
- Servidor e alojamento: a máquina onde corre, a sua largura de banda e o seu armazenamento.
- Backups e alta disponibilidade: um fluxo crítico que cai sem cópia é um incidente, não uma automação.
- Atualizações e patches de segurança: cada versão traz correções para aplicar; um motor aberto e sem patches é uma porta aberta.
- Monitorização e logs: sem observabilidade não sabes que o fluxo falhou até alguém se queixar.
- A pessoa que o mantém: o custo dominante. Não é o software, é o tempo técnico de o manter saudável.
Self-host e RGPD: soberania do dado, não uma casinha
Alojares tu a ferramenta mantém o motor e a sua base de dados dentro do teu perímetro. É um bom ponto de partida para o RGPD, mas não fecha o tema. A soberania do dado é decidida por a cadeia inteira do fluxo, não pela etiqueta do painel.
O ponto cego habitual: o motor está em casa, mas o fluxo chama uma API de LLM alojada nos Estados Unidos, ou dispara um webhook para terceiros, ou guarda um anexo num armazenamento cloud. Em cada um desses saltos o dado sai do teu perímetro tal como com um SaaS. Auto-alojar o orquestrador e mandar conteúdo sensível para um modelo externo sem controlo é meia soberania. É preciso olhar para onde vive cada salto — e é aí que o n8n auto-alojado brilha face às alternativas cloud, precisamente porque podes manter a cadeia inteira debaixo do teu teto.
Como escolher numa frase
Equipa pouco técnica e liberdade de licença total → Activepieces (MIT). Equipa mista que valoriza comunidade e integrações → n8n (fair-code). Equipa de engenharia que quer tudo como código e versionado em Git → Windmill (AGPLv3). E um aviso que poupa projetos: se o teu problema real é que o fluxo precisa de critério, nenhuma das três o resolve sozinha — isso é uma camada de IA por cima, não uma troca de ferramenta.