PARTAGE

Le 21 juin 2025 | Update 18 juillet 2025 | 8 mins read

Installer et configurer une instance self-hosted de n8n Community Edition

Introduction

n8n est une plateforme d’automatisation de workflows puissante, open-source et extensible, qui connaît un engouement croissant notamment grâce à ses intégrations natives des technologies d’intelligence artificielle. Classé parmi les outils « no-code » ou « low-code », n8n permet de concevoir des automatisations complexes en limitant l’écriture de code. Toutefois, dans la pratique, l’usage de nœuds de type "Code" devient rapidement incontournable pour gérer efficacement la donnée et éviter beaucoup d'étapes (Noeuds) dans un workflow. Beaucoup comparent n8n à d'autres outils comme Zapier ou Make mais je le comparerai plutôt à un pipedream plus centré api / code / développeur. J'exagère sans doute.

n8n n’est pas conçu pour le traitement de données en masse, mais plutôt pour manipuler des données de manière unitaire afin de faciliter les intégrations entre applications. Il peut également servir de backend low-code pour enrichir des applications existantes avec des automatisations ou ajouter des fonctionnalités personnalisées rapidement.

La version Cloud de n8n permet un démarrage rapide, mais elle reste payante et soumise à certaines limitations. Dans cet article, nous allons nous concentrer sur la version Community Edition (gratuite), que nous allons installer dans un container LXC hébergé sur Proxmox VE, une solution légère, flexible et bien adaptée à un hébergement auto-géré.

Nous verrons en détail :

  • Comment créer et configurer une instance n8n dans un container LXC via un script communautaire.
  • Comment exposer cette instance en HTTPS via Nginx Proxy Manager.

Et enfin, nous réaliserons une analyse comparative entre la version Community Edition et la version Cloud (Starter ou Pro), pour mieux orienter votre choix selon vos besoins (auto-hébergement, scalabilité, travail en équipe, maintenance, etc.).

Comment installer n8n Community Edition

La version Community Edition de n8n peut être installée de différentes manières selon vos préférences et les contraintes de votre infrastructure. Voici un éventail des options disponibles.

Docker

La méthode la plus répandue repose sur l’usage de Docker. Grâce à un simple fichier docker-compose.yml, vous pouvez lancer une instance n8n isolée et rapidement opérationnelle. Cette méthode est idéale pour les environnements multi-plateformes ou les utilisateurs familiers avec la conteneurisation.

Node.js

Pour un déploiement sans conteneur, n8n peut aussi être installé via npm ou yarn sur une machine Linux classique (Debian, Ubuntu, etc.). Cette approche convient pour des tests locaux ou des environnements simples, mais demande davantage de configuration manuelle et de gestion des dépendances.

LXC

Moins répandue mais tout aussi efficace, l’installation dans un container LXC sous Proxmox VE offre une solution légère, performante et facile à maintenir. Les containers LXC sont plus rapides à démarrer que des machines virtuelles classiques et consomment moins de ressources.

Dans mon cas, ce choix s’est imposé naturellement, puisque j’utilise déjà Proxmox pour d’autres services tels que Home Assistant, Nginx Proxy Manager, Uptime Kuma, etc...

Création du container LXC

Pour simplifier le déploiement, j’ai utilisé un script communautaire maintenu par la communauté Proxmox.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/n8n.sh)"

Le lien du script d'installation pour n8n : https://community-scripts.github.io/ProxmoxVE/scripts?id=n8n

Pour mettre à jour le container et donc n8n, il suffit d'exécuter dans le shell du container, la commande : "update"

Environnement n8n

Une fois le container installé, il faut se connecter au shell du container via l'interface de proxmox.

Taper :

cd /etc/systemd/system
nano n8n.service

Il faut modifier le fichier du service n8n pour ajouter nos variables d'environnements personnalisées. Vous retrouverez la liste des variables d'environnements de n8n sur la documentation officielle.

La variable la plus importante à mon sens est "WEBHOOK_URL". Il faut renseigner ici l'url qui servira pour accéder à notre instance n8n depuis l'extérieur du réseau local. C'est important, notamment pour la définition des urls pour les webhooks, les chats intégrés, etc... et pour créer des crédentials nécessitant une url de callback (oauth2).

[Unit]
Description=n8n

[Service]
Type=simple
Environment="N8N_SECURE_COOKIE=false"
Environment="WEBHOOK_URL=https://n8n.tondomaine.tonextension/"
Environment="N8N_EDITOR_BASE_URL=https://n8n.tondomaine.tonextension/"
Environment="EXECUTIONS_DATA_SAVE_ON_ERROR=all"
Environment="EXECUTIONS_DATA_SAVE_ON_SUCCESS=all"
Environment="EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false"
Environment="EXECUTIONS_DATA_SAVE_ON_PROGRESS=false"
Environment="EXECUTIONS_DATA_PRUNE=true"
Environment="EXECUTIONS_DATA_MAX_AGE=1000"
Environment="EXECUTIONS_DATA_PRUNE_MAX_COUNT=50"
Environment="DB_SQLITE_VACUUM_ON_STARTUP=true"
Environment="N8N_METRICS=true"
Environment="QUEUE_HEALTH_CHECK_ACTIVE=true"
Environment="N8N_DEFAULT_LOCALE=en"
Environment="GENERIC_TIMEZONE=Europe/Paris"
ExecStart=n8n start
[Install]
WantedBy=multi-user.target

Reload et recharger le service n8n. Ou redémarrer le container.

# Redémarer le service n8n
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart n8n

Accès externe via Nginx Proxy Manager

Pour accéder à n8n depuis l’extérieur (en HTTPS), j’utilise Nginx Proxy Manager (NPM). C’est une interface web simplifiée pour configurer des proxys Nginx, la gestion des certificat let's encrypt y est simplifiée.

Nginx proxy manager gère les certificats SSL via son extension let's encrypt dans l'onglet "SSL Certificates". J'utilise duckdns personnellement pour le nom de domaine. J'ai donc créé un certificat avec comme provider "duckdns". Pour les domaines, j'ai déclaré : mondomaine.duckdns.org plus : *.mondomaine.duckdns.org pour que le certificat https soit valide pour tous les sous domaines.

Quand votre certificat ssl est créé, il faut maintenant ajouter un Proxy.

Hosts => Proxy Hosts => Add Proxy Host

n8n écoute de base sur le http (Scheme).

Forward Hostname correspond à l'ip local sur votre reseau local de votre instance n8n.

Port 5678 = port par défaut.

Dans l'onglet SSL, sélectionnez le certificat correspond au nom de domaine.

Le service est maintenant accessible via https://n8n.tondomaine.tonextension/ protégé par un certificat https valide. Attention selon votre nom de domaine, il faudra peut être déclarer un sous-domaine.

Community Edition vs Cloud

Avantages de la Community

  • Sans limitations de workflow ou d'exécution.
  • Contrôle total sur l’environnement, les données et les mises à jour.
  • Sécurité : vos données ne quittent pas votre infrastructure.
  • Gratuit ou le coût d'un VPS/d'une VM/d'une instance docker dans coolify par exemple...

Inconvénients de la Community

  • Maintenance à votre charge : mises à jour, sauvegardes, sécurité
  • Infrastructure requise : un serveur, un domaine, du temps
  • Aucune fonction "enterprise" avancée (log, secret , environnement, variable, git, sso, ldap)

Version Cloud (Starter / Pro)

  • Prête à l’emploi en quelques clics
  • Support technique / Support officiel
  • Idéal pour des utilisateurs moins techniques.
  • Limitations sur le nombre d’exécutions et de workflows

Version Enterprise (Cloud ou Self-Hosted)

=> Le meilleur des deux mondes ?

Pour quelques workflows, du POCs, la version Community avec des instances dites de "dev" et "prod" suffira mais si le nombre de workflows vient à augmenter, une version entreprise deviendra sans doute bien plus adapté pour travailler en équipe, tester, itérer et déployer efficacement en mode DevOps. Autrement, il faudra mettre en oeuvre des process complexes pour travailler efficacement.

Résumé

Déployer n8n Community Edition dans un container LXC sous Proxmox représente une solution économique et robuste, idéale pour les utilisateurs expérimentés souhaitant garder un contrôle total sur leur environnement d’automatisation.

La version Community est parfaitement adaptée aux développeurs, automaticiens, makers ou petites structures maîtrisant leur stack technique. Elle requiert cependant une implication sur la maintenance (mises à jour, sécurité, sauvegardes). À l’inverse, la version Cloud payante apporte simplicité et support, mais au prix de limitations fonctionnelles (workflows, exécutions, environnement partagé).

En résumé :

  • Pour un usage personnel ou professionnel à petite échelle, réaliser des POCs : la Community Edition auto-hébergée est une excellente base.
  • Pour un usage collaboratif à grande échelle ou des besoins avancés (secret, git, gestion d’environnements, SSO…) : la version "Enterprise" sera quasi obligatoire. Il faudra aussi aller plus loin dans la configuration de n8n avec un fonctionnement en mode "queue", une db postgre pour remplacer sqlite de base et des instances n8n en mode "worker" pour scaler la charge.