Alternativas ao n8n self-hosted comparadas

O que usar em vez do n8n

As alternativas ao n8n com alojamento próprio que merecem atenção num VPS (servidor privado virtual) são Activepieces, Windmill, Node-RED, Automatisch e Huginn. O Activepieces é a substituição mais próxima da forma como a maioria das pessoas usa o n8n, e o seu núcleo está licenciado ao abrigo da MIT. O Windmill é adequado para uma equipa que prefira escrever Python ou TypeScript em vez de arrastar blocos numa tela. O Node-RED é a opção mais simples e não precisa de nenhuma base de dados.

Muitos leitores devem continuar como estão. A licença do n8n permite a utilização interna por empresas, por isso, se executar fluxos para a sua própria empresa, a licença não é um problema. A migração também não é gratuita. Nenhuma das opções desta lista lê uma exportação do n8n, pelo que terá de reconstruir cada fluxo manualmente e voltar a introduzir cada credencial. Instalar o próprio n8n é uma tarefa separada, descrita em instalação do n8n num VPS com Docker e HTTPS, e n8n comparado com Zapier e Make explica como toda esta categoria se compara com os serviços alojados.

Por que procurar alternativas self-hosted ao n8n

Dois motivos surgem repetidamente.

O primeiro é a licença. O n8n é distribuído ao abrigo da Sustainable Use License v1.0, que o projeto chama fair-code, e não open source. A licença concede o direito de "utilizar ou modificar o software apenas para os seus próprios fins empresariais internos ou para utilização não comercial ou pessoal" e proíbe disponibilizar o software comercialmente a outras pessoas. Os ficheiros e diretórios cujo nome contém .ee estão abrangidos por uma n8n Enterprise License separada. Se quiser executar automações em nome de clientes pagantes, isto é uma limitação definitiva. Se for uma equipa interna de operações, isso não altera nada no seu trabalho diário.

O segundo é a memória. O n8n é um processo Node.js, e os dados dos workflows permanecem na memória enquanto a execução decorre. A documentação do n8n identifica as causas: a quantidade de dados JSON, o tamanho dos dados binários, o número de nós num workflow, o nó Code, as execuções manuais (que copiam novamente os dados para o editor) e outros workflows em execução ao mesmo tempo. A correção documentada não é utilizar outro produto. É usar o queue mode com processos worker separados e Postgres em vez do ficheiro SQLite predefinido em ~/.n8n/database.sqlite. Os trabalhos grandes também beneficiam de processamento em lotes, porque um nó Loop Over Items que alimenta um sub-workflow mantém apenas uma parte dos dados na memória de cada vez. Experimente isto antes de reconstruir sessenta flows noutro local.

Quais alternativas self-hosted ao n8n continuam a ser mantidas

O texto da licença é fácil de ler, por isso todos comparam licenças. A saúde do projeto é fácil de ignorar. Estes são os 6 projetos incluídos nesta comparação, com a versão mais recente identificada por tag que cada um tinha em 4 August 2026.

[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

Duas linhas alteram a lista de opções. A versão mais recente do Automatisch foi identificada por tag em v0.15.0, há 361 dias, e o seu branch predefinido não recebe commits desde 15 January 2026. O Huginn teve uma versão identificada por tag 1447 dias atrás, mas o seu log de commits está ativo este mês. O padrão é o oposto: o código continua a avançar, mas as versões não são publicadas. Executá-lo significa executar uma imagem sem tag.

Verifique isto antes de confiar em qualquer comparação, incluindo esta. Abra a página de versões do projeto no GitHub e, em seguida, a lista de commits do seu branch predefinido. Um projeto com uma versão recente e um log de commits silencioso está apenas a manter o funcionamento. Um projeto com commits recentes e sem uma versão há anos está a pedir que execute código para o qual ninguém criou uma versão.

Activepieces: a alternativa mais próxima, com núcleo sob licença MIT

Activepieces é a opção equivalente. É um construtor visual com acionadores e etapas, que chama de pieces, e o README indica mais de 280. Cada piece também é exposto como um servidor MCP (model context protocol), permitindo que um cliente LLM (large language model) invoque os mesmos conectores como ferramentas. O núcleo está sob licença MIT. Dois diretórios, packages/ee/ e packages/server/api/src/app/ee, estão sob uma licença comercial, e usar o conteúdo deles no seu próprio servidor exige um contrato pago.

Leia essa divisão antes de migrar, porque ela é mais ampla do que na maioria dos projetos MIT. A página de preços do Activepieces descreve a Community Edition como "open source, free forever, with no cap on runs, users, or flows" e coloca Agents and Chat, Projects, API access e toda a camada de administração (single sign-on, user roles, audit logs, secret managers, branding, Git sync) fora dela. Portanto, a Community Edition é um mecanismo de automação completo, com flows e usuários ilimitados, mas não é uma plataforma que possa ser controlada por uma API. Se o seu plano era gerar flows programaticamente, esse plano exige uma licença.

A arquitetura de execução inclui um container da aplicação, um ou mais containers de worker, Postgres e Redis. AP_DB_TYPE=POSTGRES e AP_REDIS_TYPE=STANDALONE são os padrões. Existe um modo com um único container, com uma base de dados incorporada e uma fila no processo (AP_DB_TYPE=PGLITE com AP_REDIS_TYPE=MEMORY), e a documentação diz que ele "is only meant for personal use or testing". Considere essa indicação literalmente. Esses modos não conseguem executar mais de uma instância, portanto sair deles à medida que o uso cresce exige uma migração, não apenas a alteração de uma flag.

Windmill: código em primeiro lugar e mais pesado do que parece

O Windmill executa scripts em Python, TypeScript, Go, Bash e SQL e depois combina-os em fluxos. Se as suas automações forem sobretudo código com uma pequena quantidade de integração à volta, adapta-se melhor do que qualquer canvas de nós.

A licença exige atenção. O código-fonte é AGPLv3 quando compilado sem o sinalizador de funcionalidades empresariais. As imagens publicadas em ghcr.io/windmill-labs/windmill são a Community Edition. Incluem código que não é open source e podem ser utilizadas gratuitamente dentro dos limites definidos. A página de preços do Windmill define esses limites em 50 utilizadores, 3 workspaces e 10 GiB de armazenamento de objetos do workspace, com execuções ilimitadas. Para uma pessoa ou uma equipa pequena, esse limite está muito distante. A questão prática não é a quota. É que o binário executado não é a compilação AGPL.

O peso é outra consideração. O próprio docker-compose.yml do Windmill inclui uma base de dados Postgres 16, um servidor, três workers predefinidos com um limite de memória de 2048M cada e um worker nativo e um proxy Caddy. A regra prática documentada é "1 worker por 1vCPU e 1-2 GB de RAM". Pode reduzir o número de réplicas numa máquina pequena. Deve saber que está a fazer essa redução, porque são os workers que executam efetivamente os seus jobs.

As funcionalidades de IA do Windmill estão documentadas como ajuda durante a criação: geração de código, criação de fluxos, chat e preenchimento de formulários. Primeiro, é necessário adicionar um recurso de fornecedor de modelos nas definições do workspace. Se pretende um passo de agente que seja executado segundo um agendamento e chame ferramentas, o nó AI Agent do n8n continua a ser a opção mais direta. criar um agente de IA no n8n explica esse cenário.

Node-RED: a opção pequena, sem qualquer base de dados

Node-RED usa a licença Apache 2.0, a mais permissiva nesta comparação. É um processo Node.js com um volume /data. Não usa Postgres. Não usa Redis. Fixe-o em nodered/node-red:5.0.4, que corresponde à versão atual.

O projeto surgiu para a integração de dispositivos IoT (internet das coisas), por isso é orientado a eventos e não a conectores. Os nós para serviços de terceiros vêm da biblioteca da comunidade e têm qualidade variável. Esse é o compromisso necessário para manter uma instalação pequena. Não existe uma etapa de agente de IA de primeira classe. Para um VPS pequeno que processa webhooks e tráfego de filas de mensagens, é a opção mais leve desta comparação que cumpre o objetivo e inicia em segundos.

Huginn e Automatisch: verifique primeiro o histórico de commits

Huginn usa a licença MIT, é escrito em Ruby on Rails e precisa de MySQL ou PostgreSQL. O modelo é baseado em agentes que monitorizam uma fonte e emitem eventos. Isto é diferente de um canvas de fluxos e não existe uma estratégia para LLM. O código ainda recebe commits, mas a última release marcada é de agosto de 2022. Por isso, executá-lo significa usar a imagem ghcr.io/huginn/huginn criada a partir do branch predefinido. Escolha-o quando o modelo de agentes corresponder ao seu problema, não como substituto geral do n8n.

Automatisch usa a licença AGPL-3.0, exceto nos ficheiros .ee, e parece uma versão mais simples do n8n: Postgres, Redis e um catálogo pequeno de aplicações. É a ferramenta que os tutoriais de instalação única continuam a recomendar. O histórico de releases recomenda esperar. Um ano sem uma release e meio ano sem um commit não são motivos para entrar em pânico se já o executa, mas são motivos para não iniciar uma nova implementação de produção com ele.

Quanto uma stack do Activepieces realmente custa em RAM

Não existe um valor de memória medido em idle e em funcionamento que alguém possa publicar por si, porque ele depende dos seus próprios flows e da quantidade de dados que transportam. O que pode consultar é o que cada fornecedor recomenda reservar. O Activepieces documenta a configuração abaixo, mas a frase ao lado é mais importante do que os números: "Um worker com concorrência 1 fica ocupado durante toda a execução de um flow (até 10 min), por isso dimensione pelo número de flows concorrentes, não pela taxa de triggers."

[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

Um worker usa 0.5 vCPU e 1 GB, e executa exatamente um flow de cada vez. O Postgres é dimensionado para 4 GB. O próprio ficheiro compose do projeto inicia cinco réplicas de worker. Com esse dimensionamento, a stack do repositório requer aproximadamente 11 GB antes de os seus flows fazerem algo significativo. Tutoriais de uma só ferramenta copiam esse ficheiro e chamam-lhe uma instalação pequena.

Num VPS com 4 GB, execute dois workers, mantenha o Postgres no mesmo projeto compose e faça medições. docker stats --no-stream mostra uma linha por contentor com a memória residente real, o que é mais útil do que qualquer valor publicado por um fornecedor ou blog. Se um contentor crescer sem limite, defina-lhe um limite, e os limites de memória no Docker Compose mostram a sintaxe.

Um arquivo compose para Activepieces em um VPS

Fixe a tag. latest significa que o próximo docker compose pull pode alterar o esquema do banco de dados sem aviso. A versão 0.86.3 é a que o projeto fixa no próprio arquivo compose em 4 de agosto de 2026.

Gere primeiro os dois segredos, usando os comprimentos especificados na documentação.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

Escreva .env ao lado do arquivo compose:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL precisa ser o endereço HTTPS público, porque, caso contrário, o Activepieces tenta usar o seu endereço IP público ao criar URLs de webhook. Todo webhook que você fornece a terceiros é criado a partir desse valor. Portanto, se ele ainda apontar para localhost, a URL colada em outro serviço nunca chegará ao seu servidor.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Esse arquivo é o compose do próprio projeto com quatro alterações: o número de workers cai de cinco para dois, a porta publicada é vinculada a 127.0.0.1 em vez de todas as interfaces, os nomes fixos dos containers são removidos porque um serviço com réplicas não pode usá-los, e o bloco de rede explícito é removido porque o compose cria uma rede automaticamente.

docker compose up -d
docker compose ps

Todo serviço deve mostrar Up, incluindo dois containers worker. Um container que reinicia em loop exibe o motivo em docker compose logs worker. Leia esse motivo antes de alterar qualquer coisa. O vínculo da porta impede que algo externo alcance a aplicação até que você coloque um reverse proxy com TLS (segurança da camada de transporte) na frente. O procedimento executar o Traefik na frente de várias aplicações compose aborda esse cenário. Mantenha .env com o modo 600 e fora do git, conforme descrito em gerenciar segredos em arquivos env do compose.

O backup que todos os guias deixam de fora

Todas estas ferramentas encriptam as credenciais armazenadas, por isso um dump da base de dados, por si só, não é um backup. Precisa do dump e da chave que o desencripta. O problema é que a maioria destas ferramentas gera essa chave automaticamente, sem informar, e guarda-a num local que não está incluído nos seus backups.

O n8n é o caso mais claro. Se nunca definir N8N_ENCRYPTION_KEY, o n8n "cria automaticamente uma chave de encriptação aleatória na primeira inicialização e guarda-a na pasta ~/.n8n". Depois usa essa chave para encriptar as credenciais antes de estas chegarem à base de dados. Faça o dump do Postgres, restaure-o num contentor novo com um volume novo, e os workflows serão restaurados, mas todas as credenciais serão ciphertext que ninguém consegue ler. Defina a variável explicitamente e use o mesmo valor em todos os workers quando executar em queue mode.

O Node-RED segue o mesmo modelo. As credenciais ficam num ficheiro encriptado próprio, e a chave é credentialSecret em settings.js. Quando não define uma chave, o runtime gera uma chave aleatória e guarda-a em _credentialSecret, no seu próprio armazenamento de configurações dentro de /data. O ficheiro de configurações fornecido por predefinição indica a consequência: "depois de definir esta propriedade, não a altere - isso impedirá o node-red de desencriptar as credenciais existentes, que serão perdidas". Faça backup de todo o volume /data, não apenas do ficheiro de flows.

O Activepieces mantém AP_ENCRYPTION_KEY no seu .env, documentado como uma "chave hexadecimal de 32 caracteres (16 bytes) usada para encriptar ligações". O Huginn mantém APP_SECRET_TOKEN no ambiente. O Automatisch tem três chaves: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY e APP_SECRET_KEY. Em cada caso, o segredo fica num ficheiro de ambiente, o que significa que esse ficheiro faz parte do backup.

O Windmill é a exceção que deve conhecer. As suas variáveis e os seus segredos são encriptados com uma chave simétrica específica do workspace, que o Windmill guarda na sua própria base de dados. Por isso, um único dump do Postgres contém as duas partes. Isto facilita as restaurações, mas também significa que o dump, por si só, é suficiente para ler todos os segredos. Proteja o ficheiro como protegeria os próprios segredos.

Para a stack do Activepieces apresentada acima, o backup consiste em dois ficheiros:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

Depois, prove que o backup funciona, porque um backup não testado é apenas uma suposição. Restaure o dump num projeto compose temporário que use um AP_ENCRYPTION_KEY deliberadamente diferente e execute um flow que use uma ligação guardada. Este falha porque o ciphertext na base de dados foi produzido com a outra chave. Repita a restauração com a chave real de .env e o mesmo flow será executado. Estas duas execuções são a única prova de que o seu backup é realmente um backup. Envie ambos os ficheiros para fora do servidor segundo um agendamento, usando backups restic de um VPS, porque um backup no mesmo disco é perdido quando o disco falha.

Quando permanecer no n8n

Permaneça se o trabalho for interno à sua própria empresa, porque é exatamente isso que a Sustainable Use License permite. Permaneça se depender de uma grande variedade de integrações, já que o n8n afirma ter mais de 1500 integrações, ou do seu nó AI Agent baseado no LangChain, para o qual nenhuma das outras opções aqui oferece uma variedade equivalente de etapas de agente prontas. A executar fluxos do n8n com Claude mostra como isso funciona na prática.

Mude para o Activepieces se quiser uma licença permissiva no núcleo de automação e uma stack que possa ler de ponta a ponta. Mude para o Windmill se os seus fluxos forem, na prática, código com uma interface de utilizador. Mude para o Node-RED se o servidor for pequeno e o trabalho tiver natureza orientada a eventos. Não mude porque um benchmark afirmou que o n8n é pesado. Meça primeiro a sua própria instância, depois leia o que vale a pena alojar por conta própria em 2026 e escolha uma vez, porque a segunda migração custa tanto como a primeira.

FAQ

Qual é a alternativa self-hosted ao n8n mais próxima do n8n?

Activepieces. A ideia é a mesma: um construtor visual em que um trigger inicia um fluxo e cada passo chama um serviço, com um catálogo amplo de conectores. O núcleo é licenciado sob a licença MIT, funciona com Postgres e Redis em Docker, e as suas pieces também funcionam como servidores MCP para clientes LLM. A limitação a ter em conta é que o acesso à API e as funcionalidades de agentes estão nos diretórios comerciais enterprise, pelo que uma instância Community Edition é operada através da interface web, e não de forma programática.

O Activepieces é realmente open source?

O núcleo é, sob a licença MIT. Dois diretórios, packages/ee/ e packages/server/api/src/app/ee, têm licenças comerciais, e a utilização dessas funcionalidades no seu próprio servidor requer uma licença paga. A página de preços do fornecedor coloca Agents and Chat, Projects, acesso à API, single sign-on, funções de utilizador, logs de auditoria, gestores de segredos, branding e sincronização com Git fora da Community Edition, enquanto as execuções, os utilizadores e os fluxos não têm limites. Portanto, é genuinamente open source para criar e executar automações, mas não é open source para a camada de equipa e governação.

Quanta RAM é necessária para o Activepieces num VPS?

A documentação do Activepieces indica 0.5 vCPU e 1 GB para cada worker, 1 vCPU e 1 GB para o contentor da aplicação, 4 GB para Postgres e 1 GB para Redis. Um worker processa um fluxo de cada vez durante toda a duração desse fluxo, pelo que o dimensionamento deve basear-se no número máximo de fluxos concorrentes, e não na frequência com que os triggers são executados. O ficheiro compose do repositório inclui cinco workers, o que corresponde a cerca de 11 GB de dimensionamento publicado. Dois workers num VPS com 4 GB são um ponto de partida razoável, e docker stats --no-stream confirma o valor real para os seus fluxos enquanto estão em execução.

O que tenho de salvaguardar para que uma restauração funcione realmente?

O dump da base de dados e a chave de encriptação, em conjunto. No Activepieces, trata-se de um pg_dump da base de dados activepieces mais o ficheiro .env que contém AP_ENCRYPTION_KEY. No n8n, são a base de dados e N8N_ENCRYPTION_KEY, que o n8n gerou dentro da pasta ~/.n8n se nunca a definiu. No Node-RED, faça backup de todo o volume /data, porque o ficheiro de credenciais e a chave que o desencripta estão ambos nesse volume. O Windmill é a exceção: a chave do workspace está dentro da própria base de dados Postgres, pelo que o dump contém tudo e deve ser protegido como se contivesse os próprios segredos.

Posso importar os meus fluxos do n8n para outra ferramenta?

Não. Estes projetos importam e exportam os seus próprios formatos de fluxo, e não os do n8n. Uma migração implica recriar cada fluxo no novo construtor e criar novamente cada credencial a partir do serviço original. Esse trabalho é o custo real da mudança, por isso conte os seus fluxos antes de decidir. Doze fluxos ocupam uma tarde. Duzentos fluxos são um projeto e, normalmente, é mais barato corrigir o consumo de memória do n8n com queue mode e Postgres do que recriá-los todos.