Installer n8n sur un NAS Synology : le guide Container Manager

Votre NAS Synology est déjà allumé 24 h/24, il est déjà chez vous, et il sait faire tourner des conteneurs Docker : c'est un candidat naturel pour héberger n8n sans louer le moindre serveur. Ce guide déroule l'installation complète via Container Manager, le gestionnaire de conteneurs de DSM : dossier partagé, projet docker-compose, le piège classique des permissions, l'accès HTTPS propre avec le reverse proxy intégré, la sauvegarde et les mises à jour. Si vous partez plutôt sur un VPS Linux classique, la démarche générale est couverte dans notre guide d'installation de n8n avec Docker — l'essentiel de ce qui suit en est la déclinaison Synology.

Pourquoi héberger n8n sur son NAS

Deux arguments pèsent lourd face à un VPS ou à n8n Cloud. Le premier est économique : la machine tourne déjà en permanence pour vos sauvegardes et vos fichiers, le coût marginal d'un conteneur n8n est proche de zéro, là où un VPS ajoute quelques euros par mois à la facture. Le second est la localisation des données : vos workflows, vos credentials et l'historique de vos exécutions restent physiquement chez vous.

Ce réflexe n'a rien d'irrationnel. L'étude « Home is safer than the cloud! » de Iulia Ion, Niharika Sachdeva, Ponnurangam Kumaraguru et Srdjan Čapkun, présentée au symposium SOUPS 2011 (voir sur Google Scholar), a montré que les experts en sécurité comme les utilisateurs non experts accordent davantage confiance au stockage local qu'au cloud pour leurs données sensibles. C'est précisément une des motivations récurrentes de l'auto-hébergement — et un NAS déjà en place est la façon la moins coûteuse d'y répondre.

Prérequis : quel Synology, quelle version de DSM

Élément	Recommandation
Modèle	NAS à processeur x86, typiquement les gammes « + » (DS224+, DS423+, DS923+, etc.)
Système	DSM 7.2 ou plus récent, avec le paquet Container Manager installé depuis le Centre de paquets
RAM	2 Go suffisent pour des workflows classiques ; 4 Go et plus pour être à l'aise
Accès	SSH activé (Panneau de configuration → Terminal & SNMP) pour l'étape des permissions

Le point bloquant est le processeur : Container Manager (qui a remplacé le paquet Docker avec DSM 7.2) n'est disponible que sur les modèles x86. Les modèles ARM d'entrée de gamme — DS223, DS124 et assimilés — ne le proposent pas dans le Centre de paquets, et il n'existe pas de contournement propre. Si vous êtes dans ce cas, un n8n sur Raspberry Pi offre une alternative « à la maison » pour quelques dizaines d'euros.

Étape 1 : créer le dossier de données

n8n stocke sa configuration, sa base SQLite et surtout sa clé de chiffrement des credentials dans /home/node/.n8n. Ce dossier doit être monté sur un dossier du NAS pour survivre aux mises à jour du conteneur.

Dans File Station, ouvrez le dossier partagé docker (créé automatiquement à l'installation de Container Manager ; sinon, créez-le via Panneau de configuration → Dossier partagé) et créez-y un sous-dossier n8n. Le chemin complet côté NAS est donc :

/volume1/docker/n8n

Étape 2 : corriger les permissions du volume (le piège classique)

C'est l'erreur numéro un des installations n8n sur Synology. Le conteneur n8n ne tourne pas en root mais avec l'utilisateur node, uid 1000. Or un dossier créé depuis File Station appartient à votre compte DSM, et l'uid 1000 n'a aucun droit d'écriture dessus. Résultat : le conteneur démarre puis crashe en boucle avec une erreur EACCES: permission denied sur /home/node/.n8n.

La correction passe par SSH. Activez l'accès SSH dans Panneau de configuration → Terminal & SNMP, connectez-vous avec un compte administrateur, puis :

# Donne la propriété du dossier à l'uid 1000 (l'utilisateur node du conteneur)
sudo chown -R 1000:1000 /volume1/docker/n8n

Faites-le avant le premier démarrage : vous économiserez un aller-retour dans les logs.

Étape 3 : créer le projet dans Container Manager

Ouvrez Container Manager → Projet → Créer. Donnez un nom au projet (n8n), choisissez /volume1/docker/n8n comme chemin (ou un dossier dédié aux projets si vous préférez séparer compose et données), sélectionnez « Créer un docker-compose.yml » et collez :

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Fuseau des triggers planifiés (Cron, Schedule)
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      # Autorise le cookie de session en HTTP — uniquement pour
      # l'accès local initial, à retirer une fois le HTTPS en place
      - N8N_SECURE_COOKIE=false
    volumes:
      # Dossier créé à l'étape 1, propriété de l'uid 1000
      - /volume1/docker/n8n:/home/node/.n8n

Validez les étapes suivantes de l'assistant (le portail web proposé par DSM n'est pas nécessaire) et lancez le projet. Container Manager télécharge l'image et démarre le conteneur ; l'onglet Journal du conteneur doit afficher Editor is now accessible.

Un mot sur N8N_SECURE_COOKIE=false, qui surprend souvent : par défaut, n8n marque son cookie de session comme secure, donc réservé aux connexions HTTPS. Comme le premier accès se fait en HTTP sur l'IP locale du NAS, sans cette variable l'écran de connexion refuse obstinément de vous laisser entrer. C'est un assouplissement temporaire, à retirer à l'étape 5. Les autres variables utiles (base PostgreSQL, exécutions, logs) sont recensées dans notre guide des variables d'environnement n8n.

Étape 4 : premier démarrage

Ouvrez http://ip-du-nas:5678 (par exemple http://192.168.1.20:5678). n8n propose de créer le compte owner — l'administrateur de l'instance. Utilisez une adresse email réelle et un mot de passe robuste : cette étape n'arrive qu'une fois.

À ce stade, l'instance fonctionne pour tout ce qui est déclenché de l'intérieur : triggers planifiés, workflows manuels, appels d'API sortants. Ce qui ne fonctionne pas encore : les webhooks entrants depuis Internet, qui exigent une URL publique en HTTPS.

Étape 5 : HTTPS propre avec le reverse proxy de DSM

DSM embarque tout ce qu'il faut pour exposer n8n proprement sur un sous-domaine, sans conteneur supplémentaire. Trois sous-étapes :

1. Le certificat. Panneau de configuration → Sécurité → Certificat → Ajouter : demandez un certificat Let's Encrypt pour votre sous-domaine (par exemple n8n.mondomaine.fr), dont l'enregistrement DNS pointe vers votre IP publique. Les ports 80 et 443 doivent être redirigés vers le NAS sur votre box pour la validation et le trafic.

2. Le reverse proxy. Panneau de configuration → Portail de connexion → Avancé → Proxy inversé → Créer :

• Source : protocole HTTPS, nom d'hôte n8n.mondomaine.fr, port 443
• Destination : protocole HTTP, nom d'hôte localhost, port 5678

Dans l'onglet En-tête personnalisé, cliquez sur Créer → WebSocket : DSM ajoute les en-têtes Upgrade et Connection indispensables à l'éditeur n8n (sans eux, l'interface se fige ou perd les résultats d'exécution en direct).

3. Les variables n8n. Retournez dans le projet Container Manager et ajustez l'environnement :

    environment:
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_HOST=n8n.mondomaine.fr
      - N8N_PROTOCOL=https
      # URL publique utilisée pour générer les adresses de webhook
      - WEBHOOK_URL=https://n8n.mondomaine.fr/
      # N8N_SECURE_COOKIE supprimée : le HTTPS est en place

Reconstruisez le projet (Action → Nettoyer puis Créer, ou simplement arrêter/démarrer après modification). Sans WEBHOOK_URL, n8n continuerait d'annoncer des URL de webhook en http://localhost:5678/…, injoignables depuis les services tiers. Une fois vos webhooks publics, pensez à les protéger — header secret, validation de signature : notre guide pour sécuriser les webhooks n8n détaille les options. Et si vous ne pouvez ou ne voulez pas ouvrir les ports 80/443 sur votre box (IP non fixe, CGNAT), le tunnel Cloudflare expose l'instance sans ouvrir le moindre port.

Sauvegarde : Hyper Backup fait le travail

Tout l'état de l'instance vit dans /volume1/docker/n8n : base SQLite (workflows, credentials chiffrés, historique) et clé de chiffrement. Une tâche Hyper Backup qui inclut le dossier partagé docker — vers un disque USB, un second NAS ou un stockage distant — suffit donc à couvrir n8n, avec versions et planification. Seule précaution : la base SQLite peut être en cours d'écriture pendant la copie ; planifiez la sauvegarde à une heure creuse (la nuit, hors exécutions planifiées) ou arrêtez le conteneur le temps de la tâche pour une copie parfaitement cohérente.

Mettre à jour l'image n8n

Container Manager signale les nouvelles images mais ne met pas à jour un projet tout seul. La procédure sûre :

1. Sauvegardez /volume1/docker/n8n (ou vérifiez qu'Hyper Backup est passé récemment).
2. Dans Container Manager → Image, téléchargez la nouvelle version de n8nio/n8n.
3. Ouvrez le projet, Action → Nettoyer, puis relancez : le conteneur repart sur la nouvelle image, les données restent dans le volume.

n8n applique ses migrations de base au démarrage, ce qui rend le retour arrière délicat sans sauvegarde. Épingler une version précise (n8nio/n8n:1.x.y) plutôt que latest évite les sauts de plusieurs versions majeures un mauvais jour — la logique complète est détaillée dans mettre à jour n8n sous Docker sans rien casser.

Les limites honnêtes d'un n8n sur NAS

Un NAS n'est pas un serveur applicatif. Trois limites à connaître avant de tout miser dessus :

• La RAM. Les modèles à 2 Go partagent cette mémoire entre DSM, les paquets Synology et vos conteneurs. Des workflows qui parsent de gros fichiers ou enchaînent des appels à des modèles IA peuvent saturer la machine — pour ces usages lourds, un VPS dédié (voir le guide d'installation Docker classique) reste le bon outil.
• Le CPU. Les Celeron/Ryzen embarqués encaissent très bien des dizaines de workflows d'API et d'emails, beaucoup moins des traitements de données massifs en Code node.
• La disponibilité résidentielle. Coupure de courant, box qui redémarre, IP qui change : rien de rédhibitoire pour un usage personnel ou une petite équipe, mais un service critique facturé à des clients mérite une infrastructure prévue pour.

Pour l'immense majorité des cas — automatisations personnelles, veille, synchronisations, notifications, petits workflows IA — le NAS est au contraire un excellent hôte : déjà payé, déjà allumé, données à la maison.

Et ensuite ?

Votre n8n tourne sur le NAS, en HTTPS, sauvegardé par Hyper Backup : il ne reste qu'à le remplir. C'est exactement le type d'instance sur lequel nos packs de workflows s'importent en quelques minutes — le Pack Inbox IA (79 €), par exemple, y ajoute un tri et des brouillons de réponse automatiques pour votre boîte mail, en gardant vos emails traités sur une machine qui vous appartient. Difficile de faire plus cohérent avec les raisons qui vous ont fait choisir le self-hosted.