Pourquoi self-héberger son moteur d'automatisation
Les plateformes d'automatisation no-code/low-code comme Zapier ou Make facturent à l'exécution et imposent des quotas qui explosent vite. En auto-hébergeant n8n ou Node-RED sur un VPS, tu supprimes ces limites : nombre d'exécutions sans quota, données qui ne quittent jamais ton serveur, et accès complet aux nœuds communautaires. n8n est orienté intégrations applicatives (CRM, bases de données, IA, webhooks) avec une logique de workflow visuelle proche de Make. Node-RED, issu d'IBM, manipule des messages JSON via un système de flux événementiel, parfait pour brancher des capteurs MQTT, transformer des payloads ou orchestrer du matériel. Les deux tournent en conteneur et se pilotent depuis un navigateur.
Ce que tu gagnes en self-hosting
- Exécutions sans quota ni facturation à la tâche, contrairement aux SaaS d'automatisation.
- Données et secrets (tokens API, identifiants) stockés exclusivement sur ton VPS.
- Accès aux nœuds/intégrations communautaires non disponibles dans les offres cloud bridées.
- Possibilité d'exécuter du code custom (JavaScript, Python) sans restriction de sandbox.
- Intégration directe avec tes services internes via le réseau Docker privé.
- Contrôle total des versions et des mises à jour, sans changement de tarif imposé.
Comparatif n8n vs Node-RED
Faites défiler le tableau
| Critère | n8n | Node-RED |
|---|---|---|
| Cas d'usage principal | Intégration d'API SaaS, workflows métier | IoT, MQTT, traitement de flux temps réel |
| Modèle d'exécution | Workflow déclenché (cron, webhook, trigger) | Flux événementiel orienté messages |
| Catalogue d'intégrations | 400+ nœuds applicatifs prêts à l'emploi | Bibliothèque de nœuds via la palette communautaire |
| Code custom | Nœuds Code (JS/Python) intégrés | Nœuds Function en JavaScript |
| Base de données | SQLite par défaut, PostgreSQL recommandé | Fichiers JSON sur disque |
| RAM conseillée | 1 à 2 Go | 512 Mo à 1 Go |
| Licence | Sustainable Use License (fair-code) | Apache 2.0 |
| Courbe d'apprentissage | Accessible, orientée non-développeurs | Logique flux, plus technique |
Prérequis selon l'outil choisi
Pour n8n, prévois un VPS avec 2 vCPU et 2 Go de RAM, et surtout PostgreSQL plutôt que SQLite dès que tu dépasses quelques workflows actifs : SQLite verrouille la base sous charge concurrente. Compte 5 Go de disque pour la base et les binaires des exécutions. Node-RED est plus frugal : 1 vCPU et 1 Go de RAM suffisent, ses flux étant stockés dans de simples fichiers JSON. Dans les deux cas : Docker Compose v2, un sous-domaine dédié (n8n.mondomaine.com ou flows.mondomaine.com) et un reverse proxy HTTPS sont indispensables, car ces interfaces exposent des secrets et ne doivent jamais tourner en HTTP nu.
Déployer n8n (ou Node-RED) sur ton VPS
Provisionner Docker et le réseau
Sur le VPS, crée un réseau Docker dédié :
docker network create automation. Il isolera n8n/Node-RED de la base de données et du reverse proxy.Démarrer PostgreSQL pour n8n
Dans le docker-compose, ajoute un service
postgres:16avec un volume persistant et des identifiants en variables d'environnement. Pour Node-RED, cette étape est inutile : un volumedata:/datasuffit.Configurer le conteneur applicatif
Pour n8n, utilise l'image
docker.n8n.io/n8nio/n8navecN8N_HOST,WEBHOOK_URL=https://n8n.mondomaine.com/etDB_TYPE=postgresdb. Pour Node-RED, l'imagenodered/node-red:latestexposée sur le port1880suffit.Lancer et vérifier
Exécute
docker compose up -d. n8n écoute sur5678, Node-RED sur1880. Vérifie les logs avecdocker compose logs -fet confirme que la base est bien connectée pour n8n.Sécuriser derrière un reverse proxy
Route le trafic via Caddy ou Traefik avec un certificat Let's Encrypt automatique. Active l'authentification :
N8N_BASIC_AUTH_ACTIVE=truepour n8n, et la directiveadminAuthdanssettings.jspour Node-RED. Sans cela, l'éditeur est accessible publiquement.Mettre en place les sauvegardes
Planifie un
pg_dumpquotidien pour la base n8n, ou un simple snapshot du volume/datapour Node-RED, déposé sur un stockage externe viacron.
Pour n8n en production, active le mode queue avec Redis et des conteneurs workers séparés : le processus principal ne fait plus qu'orchestrer, tandis que les workers exécutent les nœuds en parallèle. Tu absorbes ainsi des pics de webhooks sans bloquer l'éditeur. Côté Node-RED, isole les nœuds Function dans un contexte VM avec functionGlobalContext restreint pour éviter qu'un flux mal écrit ne plante tout le runtime.
n8n vs Node-RED : différences de licence et de modèle économique
La différence de licence est le premier critère à évaluer avant tout déploiement d'entreprise. Node-RED est publié sous licence Apache 2.0 : tu peux l'utiliser, le modifier et l'intégrer dans un produit commercial sans restriction ni redevance. n8n utilise la Sustainable Use License (également appelée fair-code) : l'usage personnel et les projets internes sont gratuits, mais si tu intègres n8n dans un produit ou service que tu commercialises, ou que tu le proposes à des tiers en tant que service géré (managed service), une licence Enterprise payante est requise. En pratique, pour une équipe qui automatise ses propres processus internes, n8n reste gratuit. Pour une agence qui livrerait l'accès n8n comme prestation à ses clients, la frontière est franchie. Node-RED n'a aucune ambiguïté : Apache 2.0 couvre tous les usages, y compris commercial, sans clause restrictive. Ce choix de licence reflète le modèle économique de chaque projet : n8n est une société commerciale qui monétise sa version cloud et ses licences Enterprise ; Node-RED est un projet de la Fondation OpenJS, sans entité commerciale derrière, maintenu par la communauté et IBM.
Ressources serveur comparées
Faites défiler le tableau
| Ressource | n8n | Node-RED |
|---|---|---|
| vCPU recommandé | 2 vCPU (minimum viable : 1) | 1 vCPU (fonctionne sur Raspberry Pi) |
| RAM recommandée | 2 Go (1 Go possible pour petits usages) | 512 Mo à 1 Go |
| Disque (application) | ~500 Mo image + 2-5 Go base PostgreSQL | ~300 Mo image + quelques Mo JSON |
| Base de données | PostgreSQL (prod) ou SQLite (dev) | Fichiers JSON sur volume |
| Redis (optionnel) | Requis pour le mode queue multi-workers | Non nécessaire |
| Usage edge/embarqué | Non adapté (trop lourd) | Oui — Raspberry Pi, ESP32 via MQTT |
Cas d'usage : n8n pour les intégrations SaaS, Node-RED pour l'IoT/edge
Le positionnement de chaque outil reflète son architecture interne. n8n brille sur les intégrations SaaS : synchronisation Slack ↔ Notion, envoi de données Stripe vers un CRM, déclenchement de workflows GitHub à partir d'un webhook, enrichissement de leads via une API IA, ou orchestration de pipelines de données entre Airtable et PostgreSQL. Il embarque 400+ nœuds avec authentification OAuth gérée, des sous-workflows réutilisables et un historique d'exécutions explorable. Node-RED est conçu pour le traitement de flux bas niveau et l'IoT : connexion à des brokers MQTT pour recevoir des données de capteurs, transformation de payloads pour alimenter une base de données temporelle comme InfluxDB, automatisation domotique via Home Assistant, ou routage d'événements matériels en temps réel. Sa logique de flux (message in → traitement → message out) est directement calquée sur le modèle publish/subscribe. Les deux outils peuvent coexister : Node-RED collecte et normalise les données matérielles, n8n les consomme via webhook pour déclencher des actions SaaS (ticket support, alerte email, mise à jour CRM). Cette combinaison est fréquente dans les projets industriels connectés.
Passer de Node-RED à n8n (ou l'inverse)
Exporter les flux existants
Dans Node-RED, exporte les flux via le menu hamburger → Export → Clipboard (format JSON). Pour n8n, utilise le menu Settings → Export → Download all workflows. Ces exports sont les seuls artefacts portables entre les deux outils.
Identifier les nœuds équivalents
Dresse la liste des nœuds utilisés et cherche leur équivalent dans l'autre outil. Les nœuds MQTT de Node-RED correspondent aux nœuds MQTT de n8n ; les nœuds HTTP Request sont présents des deux côtés. Les nœuds spécialisés (InfluxDB, OPC-UA) n'ont pas toujours d'équivalent direct dans n8n : il faudra passer par un nœud HTTP Request ou du code custom.
Recréer manuellement sur staging
Il n'existe pas de convertisseur automatique entre les deux formats. Recrée les workflows manuellement sur un environnement de staging isolé. Commence par les flux les plus simples pour valider la logique avant les flux critiques.
Valider les webhooks et les triggers
Les webhooks n8n ont une URL de format
/webhook/<uuid>différente de Node-RED (/endpoint). Mets à jour tous les systèmes qui appellent ces URLs. Pour les triggers MQTT, vérifie que le client ID et les topics sont repris à l'identique.Basculer le trafic et surveiller
Une fois validé sur staging, bascule les webhooks sources un par un vers le nouvel outil. Garde l'ancien actif en parallèle quelques jours pour comparer les volumes d'exécutions. Démonte l'ancien environnement seulement après confirmation de la parité.
Quand choisir Node-RED plutôt que n8n
- Ton projet implique du matériel connecté : capteurs MQTT, GPIO, protocoles industriels (OPC-UA, Modbus) — Node-RED est conçu pour ça.
- Tu as besoin d'une licence 100 % open source sans clause d'usage commercial : Apache 2.0 n'a aucune restriction.
- Tes ressources sont contraintes : Raspberry Pi, VPS 512 Mo, ou edge device — Node-RED tourne là où n8n ne peut pas.
- Ta stack embarque déjà un broker MQTT (Mosquitto, EMQX) et une base temporelle (InfluxDB) : Node-RED s'y intègre nativement.
- Ton équipe est technique et à l'aise avec le modèle flux/message : la courbe d'apprentissage de Node-RED est plus raide mais l'outil est plus souple sur les flux bas niveau.
- Tu veux éviter une dépendance à une entité commerciale : Node-RED est gouverné par la Fondation OpenJS, sans risque de changement de licence.
Tu peux déployer n8n et Node-RED sur le même VPS via Docker Compose en leur attribuant des ports différents (5678 pour n8n, 1880 pour Node-RED) et en les isolant sur des réseaux Docker distincts. Crée un réseau automation-n8n pour n8n + PostgreSQL + Redis, et un réseau automation-nodered pour Node-RED + Mosquitto. Le reverse proxy (Caddy ou Traefik) est le seul point de contact entre les deux sous-réseaux et l'extérieur. Cette architecture te permet d'utiliser Node-RED pour la collecte IoT et n8n pour les actions SaaS sur la même machine, sans que les deux runtimes puissent communiquer directement entre eux — un flux Node-RED envoie ses données via webhook HTTP vers n8n, ce qui maintient un couplage lâche et facilite la migration future.
