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, vous supprimez ces limites : nombre d'exécutions illimité, données qui ne quittent jamais votre 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 vous gagnez en self-hosting
- Exécutions illimitées sans facturation à la tâche, contrairement aux SaaS d'automatisation.
- Données et secrets (tokens API, identifiants) stockés exclusivement sur votre 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 vos services internes via le réseau Docker privé.
- Contrôle total des versions et des mises à jour, sans changement de tarif imposé.
| 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évoyez un VPS avec 2 vCPU et 2 Go de RAM, et surtout PostgreSQL plutôt que SQLite dès que vous dépassez quelques workflows actifs : SQLite verrouille la base sous charge concurrente. Comptez 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.ma ou flows.mondomaine.ma) 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 votre VPS
Provisionner Docker et le réseau
Sur le VPS, créez 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, ajoutez un service postgres:16 avec un volume persistant et des identifiants en variables d'environnement. Pour Node-RED, cette étape est inutile : un volume data:/data suffit.
Configurer le conteneur applicatif
Pour n8n, utilisez l'image docker.n8n.io/n8nio/n8n avec N8N_HOST, WEBHOOK_URL=https://n8n.mondomaine.ma/ et DB_TYPE=postgresdb. Pour Node-RED, l'image nodered/node-red:latest exposée sur le port 1880 suffit.
Lancer et vérifier
Exécutez docker compose up -d. n8n écoute sur 5678, Node-RED sur 1880. Vérifiez les logs avec docker compose logs -f et confirmez que la base est bien connectée pour n8n.
Sécuriser derrière un reverse proxy
Routez le trafic via Caddy ou Traefik avec un certificat Let's Encrypt automatique. Activez l'authentification : N8N_BASIC_AUTH_ACTIVE=true pour n8n, et la directive adminAuth dans settings.js pour Node-RED. Sans cela, l'éditeur est accessible publiquement.
Mettre en place les sauvegardes
Planifiez un pg_dump quotidien pour la base n8n, ou un simple snapshot du volume /data pour Node-RED, déposé sur un stockage externe via cron.
Pour n8n en production, activez 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. Vous absorbez ainsi des pics de webhooks sans bloquer l'éditeur. Côté Node-RED, isolez les nœuds Function dans un contexte VM avec functionGlobalContext restreint pour éviter qu'un flux mal écrit ne plante tout le runtime.