n8n sur Proxmox : bien configurer LXC ou VM

Quiconque souhaite héberger soi-même n8n et exploite déjà un environnement Proxmox VE se pose la question de savoir si l'automatisation des workflows doit s'exécuter dans un conteneur LXC ou dans une machine virtuelle complète. Pour la plupart des petites et moyennes entreprises, un conteneur LXC non privilégié avec les fonctions nesting et keyctl activées est la solution la plus pragmatique, car il mobilise nettement moins de ressources qu'une VM et peut faire fonctionner n8n dans un conteneur Docker. Quiconque a besoin d'une isolation maximale sans compromis devrait en revanche opter pour la VM. Situation en date de : juillet 2026.

LXC ou VM : la décision de fond

n8n en tant que tel n'impose aucune exigence spécifique à Proxmox ; la décision se joue uniquement au niveau de la technique de virtualisation. Un conteneur LXC partage le noyau avec l'hôte Proxmox, démarre très rapidement et nécessite nettement moins de mémoire vive qu'une VM comparable. L'inconvénient : deux niveaux de conteneurs, LXC et Docker, partagent le même noyau, une mise à jour du noyau sur l'hôte peut en cas de doute affecter les deux niveaux simultanément. Une VM isole complètement n8n et le démon Docker qui y fonctionne de l'hôte, mais coûte en contrepartie plus de mémoire et de puissance de calcul pour son propre noyau. Pour un seul serveur n8n dans une petite entreprise, la différence de ressources est en pratique généralement plus déterminante que la question théorique de l'isolation.

Docker dans le conteneur LXC : bien configurer nesting et keyctl

Pour qu'un démon Docker puisse fonctionner à l'intérieur d'un conteneur LXC, le conteneur doit être équipé d'interfaces noyau supplémentaires. Dans la documentation Proxmox sur les options des conteneurs la fonction nesting y est décrite ainsi : "Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest." Sans cette option, le démon Docker dans le conteneur échoue régulièrement au démarrage. De plus, Docker dans un conteneur non privilégié a besoin de l'option keyctl, que Proxmox documente ainsi : "For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container." Point important : selon la documentation Proxmox, quiconque active keyctl pour Docker ne peut pas utiliser simultanément systemd-networkd dans la même configuration, car les deux fonctions revendiquent le même traitement des appels système. Les deux options peuvent être définies dans la configuration du conteneur sous "Features". Un conteneur privilégié n'est pas recommandé pour un usage en production, car Proxmox ne traite explicitement pas les nouveaux exploits d'évasion issus de conteneurs privilégiés avec la même priorité que ceux issus de conteneurs non privilégiés.

Installer n8n via Docker

Une fois le conteneur LXC préparé, l'installation proprement dite de n8n suit les mêmes étapes que sur n'importe quel autre hôte Docker. Selon la documentation Docker officielle de n8n un volume Docker est d'abord créé et n8n est démarré avec un mappage de port sur 5678, les variables de fuseau horaire TZ et GENERIC_TIMEZONE, ainsi qu'un répertoire de données monté. Selon la documentation, ce répertoire situé sous /home/node/.n8n contient "encryption keys, instance logs, and source control feature assets" et, dans la configuration par défaut, en plus la base de données SQLite avec tous les workflows et identifiants. Quiconque souhaite plutôt connecter une base de données PostgreSQL externe ajoute les variables d'environnement correspondantes pour l'hôte, le port, le nom de la base de données et les identifiants ; selon n8n, le répertoire de données reste néanmoins pertinent dans ce cas également, car des données importantes continuent d'y résider. Au même endroit, n8n indique explicitement que l'auto-hébergement requiert des connaissances techniques en matière d'exploitation de serveur, de gestion des ressources et de sécurité, et s'adresse à des utilisateurs expérimentés. Quiconque ne souhaite pas gérer lui-même cette installation trouvera chez NordFlux un accompagnement pour la configuration et le suivi de n8n.

Sauvegarde : les snapshots Proxmox en complément de la sauvegarde propre à n8n

Un conteneur LXC peut être sauvegardé via la fonction de sauvegarde propre à Proxmox, qui pour les conteneurs, selon la documentation de sauvegarde Proxmox fonctionne au choix en mode Stop, Suspend ou Snapshot. En mode Snapshot, le conteneur est brièvement mis en pause, un instantané de stockage temporaire est créé, puis le contenu est sauvegardé sous forme d'archive avant que l'instantané ne soit à nouveau supprimé. Cela sauvegarde de manière fiable l'état complet du conteneur, y compris le démon Docker et le répertoire de données n8n, mais ne remplace pas une sauvegarde au niveau de l'application. Quiconque souhaite sauvegarder spécifiquement uniquement les workflows et les identifiants devrait en plus exporter régulièrement le répertoire de données propre à n8n, car un instantané Proxmox sauvegarde toujours l'ensemble du conteneur et, en cas d'urgence, prend plus de temps que la restauration ciblée de workflows individuels. En pratique, une combinaison est recommandée : des sauvegardes Proxmox planifiées pour la restauration complète du serveur et un export supplémentaire, plus fréquent, des workflows n8n pour les cas individuels rapides.

Questions fréquentes sur n8n sur Proxmox

Ai-je absolument besoin de nesting et keyctl si je veux utiliser Docker dans un conteneur LXC ?

Oui, selon la documentation Proxmox, les deux options sont nécessaires pour Docker dans un conteneur LXC non privilégié, sinon le démon Docker ne démarre pas de manière fiable ou certaines fonctions échouent.

Un conteneur privilégié est-il la solution la plus simple ?

Techniquement, souvent oui ; sur le plan de la sécurité, non. Proxmox ne traite pas les nouveaux exploits d'évasion issus de conteneurs privilégiés avec la même priorité que ceux issus de conteneurs non privilégiés. Pour un serveur n8n utilisé en production avec des identifiants stockés, c'est un risque que la plupart des entreprises ne devraient pas prendre.

Un snapshot Proxmox suffit-il comme seule sauvegarde pour n8n ?

Un snapshot sauvegarde l'ensemble du conteneur de manière fiable, mais il est grossier et peu pratique pour restaurer des workflows individuels. Il est plus judicieux de combiner une sauvegarde Proxmox régulière avec un export supplémentaire et ciblé des workflows n8n.

n8n fonctionne-t-il de manière plus stable dans une VM que dans le conteneur LXC ?

Pas fondamentalement plus stable, mais plus isolé. Une VM isole complètement le démon Docker du noyau de l'hôte, ce qui coûte des ressources, mais réduit le risque qu'une mise à jour du noyau sur l'hôte Proxmox affecte les deux niveaux de conteneurs en même temps.