Alternatives auto-hébergées à n8n : comparatif

Que choisir à la place de n8n

Les alternatives à n8n auto-hébergées qui méritent votre attention sur un VPS (virtual private server) sont Activepieces, Windmill, Node-RED, Automatisch et Huginn. Activepieces est le remplacement le plus proche de l’utilisation que la plupart des personnes font de n8n, et son cœur est sous licence MIT. Windmill convient à une équipe qui préfère écrire du Python ou du TypeScript plutôt que de déplacer des blocs sur un canvas. Node-RED est la solution la plus légère et ne nécessite aucune base de données.

De nombreux utilisateurs peuvent rester avec n8n. La licence n8n autorise l’utilisation interne en entreprise. Si vous exécutez des flows pour votre propre société, la licence ne pose donc pas de problème. La migration n’est pas gratuite non plus. Aucun outil de cette liste ne peut lire un export n8n. Vous devez donc recréer chaque flow manuellement et saisir à nouveau chaque credential. L’installation de n8n est un sujet distinct, traité dans l’installation de n8n sur un VPS avec Docker et HTTPS. La comparaison n8n face à Zapier et Make explique comment l’ensemble de cette catégorie se compare aux services hébergés.

Pourquoi chercher des alternatives auto-hébergées à n8n

Deux raisons reviennent régulièrement.

La première concerne la licence. n8n est distribué sous la Sustainable Use License v1.0, que le projet qualifie de fair-code plutôt que d’open source. Cette licence autorise à « utiliser ou modifier le logiciel uniquement pour ses propres besoins professionnels internes, ou pour un usage non commercial ou personnel », mais interdit de fournir commercialement le logiciel à d’autres personnes. Les fichiers et dossiers dont le nom contient .ee relèvent d’une n8n Enterprise License distincte. Si vous voulez exécuter des automatisations pour le compte de clients payants, c’est un point bloquant. Si vous faites partie d’une équipe interne chargée des opérations, cela ne change rien à votre utilisation quotidienne.

La seconde concerne la mémoire. n8n est un processus Node.js, et les données du workflow restent en mémoire pendant son exécution. La documentation de n8n cite plusieurs causes : la quantité de données JSON, la taille des données binaires, le nombre de nœuds dans un workflow, le nœud Code, les exécutions manuelles (qui recopient également les données pour l’éditeur) et les autres workflows exécutés simultanément. La correction documentée n’est pas de choisir un autre produit. Il faut utiliser le queue mode avec des processus worker séparés, ainsi que Postgres au lieu du fichier SQLite par défaut situé à ~/.n8n/database.sqlite. Les tâches volumineuses nécessitent également un traitement par lots, car un nœud Loop Over Items qui alimente un sous-workflow ne conserve qu’une seule portion des données en mémoire à la fois. Essayez cette approche avant de reconstruire soixante workflows ailleurs.

Quelles alternatives auto-hébergées à n8n sont encore maintenues

Le texte de la licence est facile à lire, donc tout le monde compare les licences. Il est facile de négliger l’état du projet. Voici les 6 projets de cette comparaison, avec la version la plus récente marquée par une release pour chacun au 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
  }
]

Deux lignes modifient la sélection. Automatisch a marqué sa dernière release il y a 361 jours, et sa branche par défaut n’a reçu aucun commit depuis le 15 January 2026. Huginn a marqué une release il y a 1447 jours, mais son journal de commits est actif ce mois-ci. Le schéma est inverse : le code évolue, mais les releases ne suivent pas. L’exécuter revient donc à utiliser une image sans version marquée.

Vérifiez vous-même ces éléments avant de vous fier à une comparaison, y compris celle-ci. Ouvrez la page des releases du projet sur GitHub, puis la liste des commits de sa branche par défaut. Un projet avec une release récente et un journal de commits silencieux fonctionne au minimum nécessaire. Un projet avec des commits récents et aucune release depuis des années vous demande d’exécuter du code pour lequel personne n’a publié de version.

Activepieces : le choix le plus proche, avec un cœur sous licence MIT

Activepieces est le choix le plus comparable. Il s’agit d’un éditeur visuel composé de déclencheurs et d’étapes, appelés pieces, et le README en annonce plus de 280. Chaque piece est également exposé comme serveur MCP (model context protocol), ce qui permet à un client LLM (large language model) d’appeler les mêmes connecteurs comme outils. Le cœur est sous licence MIT. Deux répertoires, packages/ee/ et packages/server/api/src/app/ee, sont soumis à une licence commerciale. L’utilisation de leur contenu sur votre propre serveur nécessite un accord payant.

Lisez attentivement cette séparation avant de migrer, car elle est plus large que dans la plupart des projets sous licence MIT. La page de tarification d’Activepieces décrit l’édition Community comme « open source, gratuite pour toujours, sans limite sur les exécutions, les utilisateurs ou les flows », et exclut de cette édition Agents et Chat, les Projects, l’accès à l’API et toute la couche d’administration (single sign-on, rôles utilisateurs, journaux d’audit, gestionnaires de secrets, branding, synchronisation Git). L’édition Community est donc un moteur d’automatisation complet avec un nombre illimité de flows et d’utilisateurs, mais ce n’est pas une plate-forme que vous pouvez piloter depuis une API. Si vous aviez prévu de générer les flows par programmation, ce projet nécessite une licence.

L’architecture d’exécution comprend un conteneur d’application, un ou plusieurs conteneurs worker, Postgres et Redis. AP_DB_TYPE=POSTGRES et AP_REDIS_TYPE=STANDALONE sont les valeurs par défaut. Un mode à conteneur unique utilise une base de données intégrée et une file d’attente dans le processus (AP_DB_TYPE=PGLITE avec AP_REDIS_TYPE=MEMORY), et la documentation précise qu’il « est uniquement destiné à un usage personnel ou aux tests ». Prenez cette indication au sérieux. Ces modes ne peuvent pas exécuter plusieurs instances. En sortir nécessite donc une migration, et non l’ajout d’un flag.

Windmill : le code d’abord, avec une empreinte plus importante qu’il n’y paraît

Windmill exécute des scripts en Python, TypeScript, Go, Bash et SQL, puis les assemble en flows. Si vos automatisations sont principalement constituées de code, avec peu de logique de liaison, il convient mieux qu’un canvas de nœuds.

La licence demande de l’attention. Le code source est sous AGPLv3 lorsqu’il est compilé sans le feature flag enterprise. Les images publiées sur ghcr.io/windmill-labs/windmill sont celles de la Community Edition. Elles incluent du code qui n’est pas open source et peuvent être utilisées gratuitement dans certaines limites. La page de tarification de Windmill fixe ces limites à 50 utilisateurs, 3 workspaces et 10 GiB de stockage d’objets par workspace, avec un nombre d’exécutions illimité. Pour une personne ou une petite équipe, ces limites sont rarement atteintes. La question pratique n’est donc pas le quota. C’est le fait que le binaire exécuté n’est pas le build AGPL.

L’empreinte est l’autre point à prendre en compte. Le docker-compose.yml de Windmill fournit une base de données Postgres 16, un serveur, trois workers par défaut avec une limite de mémoire de 2048M chacun, un worker natif et un proxy Caddy. La règle empirique documentée est la suivante : « 1 worker par vCPU et 1-2 GB de RAM ». Vous pouvez réduire le nombre de replicas sur une petite machine. Vous devez savoir que vous le réduisez, car ce sont les workers qui exécutent réellement vos jobs.

La documentation présente les fonctionnalités d’IA de Windmill comme une aide à la conception : génération de code, création de flows, chat et remplissage de formulaires. Vous devez d’abord ajouter une resource de fournisseur de modèles dans les paramètres du workspace. Si vous voulez une étape d’agent qui s’exécute selon un calendrier et appelle des tools, le nœud AI Agent de n8n reste l’option la plus directe. Créer un agent IA dans n8n décrit ce cas de figure.

Node-RED : le plus léger, sans aucune base de données

Node-RED est sous licence Apache 2.0, la licence la plus permissive de cette comparaison. Il s’agit d’un seul processus Node.js avec un volume /data. Pas de Postgres. Pas de Redis. Épinglez-le sur nodered/node-red:5.0.4, qui correspond à la version actuelle.

Node-RED est issu du câblage IoT (Internet des objets). Son fonctionnement repose donc sur des événements plutôt que sur des connecteurs. Les nœuds pour les services tiers proviennent de la bibliothèque communautaire et leur qualité varie. C’est le compromis d’une faible empreinte. Il n’existe pas d’étape d’agent IA native. Pour un petit VPS qui gère des webhooks et du trafic de files de messages, c’est la solution la plus légère de cette sélection qui soit réellement opérationnelle. Elle démarre en quelques secondes.

Huginn et Automatisch : consultez d’abord l’historique des commits

Huginn est sous licence MIT, écrit en Ruby on Rails, et nécessite MySQL ou PostgreSQL. Il fonctionne avec des agents qui surveillent une source et émettent des événements. Ce modèle diffère d’un canvas de flux, et Huginn ne propose rien pour les LLM. Le code reçoit encore des commits, mais la dernière release taguée date d’août 2022. L’exécuter revient donc à utiliser l’image ghcr.io/huginn/huginn construite depuis la branche par défaut. Choisissez-le si le modèle d’agents correspond à votre problème, et non comme remplacement général de n8n.

Automatisch est sous licence AGPL-3.0, à l’exception de ses fichiers .ee, et ressemble à une version plus simple de n8n : Postgres, Redis et un petit catalogue d’applications. C’est l’outil que les tutoriels de déploiement unique continuent de recommander. L’historique des releases invite à attendre. Une année sans release et six mois sans commit ne justifient pas de paniquer si vous l’exécutez déjà. En revanche, c’est une raison de ne pas lancer un nouveau déploiement en production avec cet outil.

Ce qu’une stack Activepieces coûte réellement en RAM

La mémoire utilisée au repos et en fonctionnement ne peut pas être chiffrée de manière générale, car elle dépend de vos propres flows et du volume de données qu’ils traitent. Vous pouvez en revanche consulter les ressources que chaque éditeur vous recommande de prévoir. Activepieces documente le dimensionnement ci-dessous. La phrase qui l’accompagne compte davantage que les chiffres : « Un worker avec une concurrence de 1 reste occupé pendant toute la durée d’un flow, jusqu’à 10 min. Dimensionnez donc selon le nombre de flows simultanés, et non selon le taux de déclenchement. »

[
  {
    "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
  }
]

Un worker correspond à 0.5 vCPU et 1 GB de RAM, et il n’exécute qu’un seul flow à la fois. Postgres est dimensionné à 4 GB. Le fichier compose du projet lance cinq réplicas de worker. Avec ce dimensionnement, la stack du dépôt demande donc environ 11 GB avant même que vos flows ne traitent une charge notable. Les tutoriels consacrés à un seul outil copient ce fichier et présentent cela comme un déploiement léger.

Sur un VPS de 4 GB, lancez deux workers, gardez Postgres dans le même projet compose et mesurez. docker stats --no-stream affiche une ligne par conteneur avec sa mémoire résidente réellement utilisée. Cette mesure est plus fiable que n’importe quel chiffre publié par un éditeur ou un blog. Si un conteneur augmente sa consommation sans limite, plafonnez-la. La section sur les limites mémoire dans Docker Compose présente la syntaxe.

Un fichier Compose pour Activepieces sur un seul VPS

Épinglez le tag. latest signifie que le prochain docker compose pull peut modifier le schéma de la base de données sans avertissement. La version 0.86.3 est celle que le projet indique dans son propre fichier Compose au 4 août 2026.

Générez d’abord les deux secrets, en utilisant les longueurs indiquées dans la documentation.

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

Placez .env à côté du fichier 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 doit être l’adresse HTTPS publique, car Activepieces essaie sinon d’utiliser votre adresse IP publique lors de la génération des URL de webhook. Chaque webhook transmis à un service tiers est généré à partir de cette valeur. S’il pointe encore vers localhost, l’URL que vous collez dans un autre service n’atteint jamais votre serveur.

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:

Ce fichier est le fichier Compose du projet, avec quatre modifications : le nombre de workers passe de cinq à deux, le port publié est lié à 127.0.0.1 au lieu de toutes les interfaces, les noms de conteneurs fixes sont supprimés, car un service avec des replicas ne peut pas les utiliser, et le bloc de réseau explicite est supprimé, car Compose en crée un automatiquement.

docker compose up -d
docker compose ps

Chaque service doit afficher Up, notamment les deux conteneurs worker. Un conteneur qui redémarre en boucle indique la cause dans docker compose logs worker. Consultez cette information avant de modifier quoi que ce soit. La liaison du port empêche toute connexion externe à l’application tant que vous n’avez pas placé un reverse proxy avec TLS (transport layer security) devant elle. Cette configuration est décrite dans exécuter Traefik devant plusieurs applications Compose. Conservez .env avec le mode 600 et excluez-le de git, comme indiqué dans gérer les secrets dans les fichiers env de Compose.

La sauvegarde que tous les guides oublient

Tous ces outils chiffrent les identifiants stockés. Un dump de base de données ne constitue donc pas une sauvegarde à lui seul. Vous avez besoin du dump et de la clé qui permet de le déchiffrer. Le piège est que la plupart de ces outils génèrent eux-mêmes cette clé, sans vous prévenir, puis la stockent à un emplacement que vous n’incluez pas dans vos sauvegardes.

n8n est le cas le plus évident. Si vous n’avez jamais défini N8N_ENCRYPTION_KEY, n8n « crée automatiquement une clé de chiffrement aléatoire au premier démarrage et l’enregistre dans le dossier ~/.n8n », puis utilise cette clé pour chiffrer les identifiants avant leur enregistrement dans la base de données. Effectuez un dump de Postgres, restaurez-le dans un nouveau conteneur avec un nouveau volume, et les workflows réapparaissent, mais chaque identifiant est un texte chiffré illisible. Définissez explicitement cette variable et utilisez la même valeur sur chaque worker lorsque vous exécutez le mode queue.

Node-RED suit le même modèle. Les identifiants sont stockés dans leur propre fichier chiffré, et la clé est credentialSecret dans settings.js. Si vous n’en définissez pas, le runtime génère une clé aléatoire et l’enregistre sous _credentialSecret dans son propre store de paramètres, à l’intérieur de /data. Le fichier de paramètres fourni indique la conséquence : « une fois cette propriété définie, ne la modifiez pas : Node-RED ne pourra plus déchiffrer vos identifiants existants et ceux-ci seront perdus ». Sauvegardez l’intégralité du volume /data, pas uniquement le fichier des flows.

Activepieces conserve AP_ENCRYPTION_KEY dans votre .env, décrit comme une « clé hexadécimale de 32 caractères (16 octets) utilisée pour chiffrer les connexions ». Huginn conserve APP_SECRET_TOKEN dans son environnement. Automatisch en utilise trois : ENCRYPTION_KEY, WEBHOOK_SECRET_KEY et APP_SECRET_KEY. Dans chaque cas, le secret se trouve dans un fichier d’environnement. Ce fichier fait donc partie de la sauvegarde.

Windmill constitue l’exception à connaître. Ses variables et ses secrets sont chiffrés avec une clé symétrique propre à l’espace de travail, que Windmill stocke dans sa propre base de données. Un dump Postgres contient donc les deux éléments. Cela simplifie les restaurations, mais signifie que le dump suffit à lire tous les secrets. Protégez ce fichier comme s’il contenait les secrets eux-mêmes.

Pour la stack Activepieces présentée plus haut, la sauvegarde se compose de deux fichiers :

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

Vérifiez ensuite que la sauvegarde fonctionne, car une sauvegarde non testée reste une supposition. Restaurez le dump dans un projet Compose de test qui utilise un AP_ENCRYPTION_KEY volontairement différent, puis exécutez un flow qui utilise une connexion enregistrée. Il échoue, car le texte chiffré de la base de données a été produit avec l’autre clé. Recommencez la restauration avec la clé réelle de .env, puis exécutez le même flow. Ces deux exécutions sont les seules preuves que votre sauvegarde est réellement exploitable. Transférez régulièrement les deux fichiers hors du serveur avec des sauvegardes restic depuis un VPS, car une sauvegarde stockée sur le même disque est perdue avec celui-ci.

Quand rester sur n8n

Restez sur n8n si le travail reste interne à votre entreprise, car c’est précisément ce qu’autorise la Sustainable Use License. Restez-y si vous privilégiez l’étendue fonctionnelle : n8n annonce plus de 1500 intégrations. Son nœud AI Agent, basé sur LangChain, est également sans équivalent ici pour les étapes d’agent prêtes à l’emploi. Piloter des workflows n8n avec Claude montre concrètement son fonctionnement.

Passez à Activepieces si vous voulez une licence permissive pour le cœur de l’automatisation et une stack que vous pouvez lire de bout en bout. Passez à Windmill si vos workflows sont en réalité du code présenté derrière une interface utilisateur. Passez à Node-RED si la machine est peu dimensionnée et si le travail est orienté événements. Ne changez pas parce qu’un benchmark vous a indiqué que n8n était lourd. Mesurez d’abord votre propre instance, puis consultez ce qu’il vaut la peine d’auto-héberger en 2026 et faites votre choix une seule fois, car la deuxième migration coûte autant que la première.

FAQ

Quelle alternative auto-hébergée à n8n est la plus proche de n8n ?

Activepieces. Le principe est identique : un builder visuel dans lequel un trigger démarre un flow et chaque étape appelle un service, avec un vaste catalogue de connecteurs. Son cœur est sous licence MIT, il s’exécute avec Postgres et Redis sous Docker, et ses pieces servent aussi de serveurs MCP pour les clients LLM. Le point à surveiller est que l’accès à l’API et les fonctions d’agent se trouvent dans les répertoires commerciaux Enterprise. Une instance Community Edition se pilote donc via son interface web, et non par programmation.

Activepieces est-il vraiment open source ?

Le cœur l’est, sous licence MIT. Deux répertoires, packages/ee/ et packages/server/api/src/app/ee, sont sous licence commerciale, et l’utilisation de ces fonctions sur votre propre serveur nécessite une licence payante. La page tarifaire de l’éditeur exclut de la Community Edition Agents et Chat, les projets, l’accès à l’API, le single sign-on, les rôles utilisateur, les audit logs, les secret managers, le branding et la synchronisation Git. En revanche, le nombre d’exécutions, d’utilisateurs et de flows n’est pas plafonné. Activepieces est donc réellement open source pour créer et exécuter des automatisations, mais pas pour la gestion d’équipe et la gouvernance.

De combien de RAM Activepieces a-t-il besoin sur un VPS ?

Activepieces indique 0.5 vCPU et 1 GB pour chaque worker, 1 vCPU et 1 GB pour le conteneur applicatif, 4 GB pour Postgres et 1 GB pour Redis. Un worker traite un seul flow à la fois, pendant toute la durée de ce flow. Vous devez donc dimensionner l’instance selon le nombre maximal de flows simultanés, et non selon la fréquence de déclenchement des triggers. Le fichier compose du dépôt lance cinq workers, soit environ 11 GB selon le dimensionnement publié. Deux workers sur un VPS de 4 GB constituent un point de départ raisonnable, et docker stats --no-stream vous permet de vérifier le nombre réel nécessaire pour vos flows pendant leur exécution.

Que dois-je sauvegarder pour qu’une restauration fonctionne réellement ?

Le dump de la base de données et la clé de chiffrement, ensemble. Pour Activepieces, il s’agit d’un pg_dump de la base de données activepieces et du fichier .env qui contient AP_ENCRYPTION_KEY. Pour n8n, il faut sauvegarder la base de données ainsi que N8N_ENCRYPTION_KEY, que n8n a généré pour vous dans le dossier ~/.n8n si vous ne l’avez jamais défini. Pour Node-RED, sauvegardez l’intégralité du volume /data, car le fichier d’identifiants et la clé qui le déchiffre s’y trouvent tous les deux. Windmill fait exception : sa clé de workspace se trouve dans sa propre base de données Postgres. Le dump contient donc tout et doit être protégé comme s’il contenait directement les secrets.

Puis-je importer mes workflows n8n dans un autre outil ?

Non. Ces projets importent et exportent leurs propres formats de flow, pas ceux de n8n. Une migration consiste à reconstruire chaque flow dans le nouveau builder et à recréer chaque identifiant à partir du service d’origine. Ce travail représente le coût réel d’un changement d’outil. Comptez donc vos flows avant de décider. Douze flows représentent un après-midi. Deux cents flows représentent un projet, et il est généralement moins coûteux de corriger l’utilisation mémoire de n8n avec le queue mode et Postgres que de tout reconstruire.