Installer n8n sur un VPS avec Docker et HTTPS

Ce que vous allez mettre en place

n8n est un outil d’automatisation de workflows : un éditeur visuel dans lequel un déclencheur, un webhook, une planification ou la soumission d’un formulaire lance une chaîne de nœuds qui appellent des API, transforment les données et les écrivent dans d’autres systèmes. Il est devenu l’outil d’intégration par défaut des workflows avec des agents IA, car il communique avec tous les fournisseurs de modèles et toutes les bases de données sans que vous ayez à développer un service. Un docker run permet d’obtenir un éditeur fonctionnel en deux minutes. Ce guide porte sur les 90 % restants : le rendre durable avec Postgres au lieu du fichier SQLite par défaut, le rendre accessible en HTTPS et, point que presque tout le monde configure mal, faire en sorte que les webhooks fournissent une URL réellement accessible depuis l’extérieur.

La stack finale se compose de deux conteneurs sur un même réseau Docker : n8n lui-même et une base de données Postgres qui contient ses workflows et ses identifiants. Un reverse proxy sur l’hôte termine TLS et redirige les requêtes vers n8n sur localhost. Rien n’est donc directement exposé sur Internet, sauf par l’intermédiaire de ce proxy. Cette installation rejoint les autres services de la sélection 2026 pour l’auto-hébergement.

Prérequis et limites à connaître

Vous avez besoin d’un VPS avec au moins 1 GB de RAM. Prévoyez 2 GB lorsque les workflows effectueront un vrai traitement, car les exécutions et le runtime Node.js consomment de la mémoire, et l’out-of-memory killer qui interrompt le conteneur en plein traitement est une très mauvaise façon de le découvrir. Un seul vCPU suffit pour commencer. Si ce serveur doit également exécuter un service plus lourd, dimensionnez-le d’abord pour ce service : une photothèque est généralement le principal facteur, et les besoins réels en RAM de PhotoPrism et d’Immich dépassent largement ceux de n8n. Même chose pour un serveur multimédia : un serveur Jellyfin et une interface permettant de parcourir sa bibliothèque, comme Halcyon, qui transforme la bibliothèque en vidéoclub des années 90, consommeront la RAM et la capacité de transcodage disponible bien avant que n8n ne s’en aperçoive.

Vous avez besoin d’un domaine ou d’un sous-domaine, par exemple n8n.example.com, avec un enregistrement A pointant vers l’adresse IP publique du VPS et qui se résout avant la demande du certificat. Les ports 80 et 443 doivent être ouverts vers le proxy. Le port 5678 utilisé par n8n ne doit pas être exposé sur Internet. Vous avez besoin de Docker Engine et du plugin Compose. Si docker compose version renvoie une erreur contenant docker: 'compose' is not a docker command, vous utilisez l’ancien binaire autonome ; le plugin est sudo apt install docker-compose-plugin.

SQLite convient pour un test, mais utilisez Postgres pour tout ce dont vous dépendez

La base de données par défaut de n8n est un fichier SQLite situé à /home/node/.n8n/database.sqlite. Pour faire un premier essai, cela convient : ne montez aucun volume et vous perdrez la base à la première recréation du conteneur. C’est déjà une leçon en soi. Le passage à Postgres n’est pas motivé par la vitesse brute. SQLite n’autorise qu’un seul verrou d’écriture. Une instance qui exécute plusieurs workflows en parallèle, ou le mode queue que vous voudrez probablement utiliser plus tard, renvoie donc SQLITE_BUSY: database is locked en cas d’accès concurrents. Postgres n’a pas cette limite, se sauvegarde correctement avec pg_dump et correspond à la configuration recommandée par la documentation de n8n pour un serveur dont vous dépendez. Passer à Postgres plus tard implique de migrer les données manuellement. Si ce serveur est important, utilisez donc Postgres dès le départ.

DNS et pare-feu

Pointez d’abord l’enregistrement DNS et ouvrez les ports. L’étape de certificat ne plantera ainsi pas plus tard à cause d’un nom qui ne se résout pas.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

N’ouvrez pas le port 5678. Le fichier Compose lie n8n à 127.0.0.1:5678 afin que seul le reverse proxy de l’hôte puisse y accéder. Un ufw allow 5678 annulerait cette isolation.

Le fichier Compose

Créez un répertoire de travail et un docker-compose.yml. Il s’agit de toute la stack : deux services, un réseau privé et deux volumes nommés.

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

Quelques décisions doivent être explicitées. DB_POSTGRESDB_HOST=postgres est le nom du service, que Docker résout sur le réseau partagé, et non localhost, qui désigne n8n lui-même à l’intérieur du conteneur n8n. Le depends_on avec condition: service_healthy empêche n8n de démarrer avant Postgres au boot ; sans lui, n8n démarre, ne trouve aucune base de données, puis s’arrête. Le volume nommé n8n_data monté sur /home/node/.n8n contient la clé de chiffrement et, avec SQLite, la base de données : c’est le seul répertoire que vous ne devez pas perdre. Épinglez l’image sur une version exacte, jamais latest ; les raisons sont expliquées dans la section sur les mises à niveau ci-dessous.

Le fichier des secrets

Ne mettez jamais de mots de passe dans le fichier Compose. Placez-les dans un fichier .env situé à côté de celui-ci, que Compose lit automatiquement. Générez-les afin qu’ils soient réellement aléatoires.

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

La N8N_ENCRYPTION_KEY est la chaîne la plus importante ici. C’est la clé utilisée pour chiffrer tous les identifiants enregistrés. Définissez-la explicitement au lieu de laisser n8n en générer une, car une valeur que vous avez générée peut être notée et restaurée. Dès que n8n a chiffré son premier identifiant avec cette clé, la modifier rend tous les identifiants impossibles à déchiffrer. Définissez-la donc une seule fois, maintenant, et ne modifiez plus jamais cette ligne.

Les variables d’environnement qui déterminent le fonctionnement des webhooks

Quatre variables contrôlent la façon dont n8n se présente à l’extérieur. Une mauvaise valeur est la principale cause des demandes d’assistance concernant n8n.

• N8N_HOST est le nom d’hôte public, n8n.example.com. Si vous conservez la valeur par défaut localhost derrière un proxy, l’éditeur essaie de charger sa propre API depuis localhost dans votre navigateur, ce qui échoue.
• N8N_PROTOCOL=https indique à n8n qu’il est servi via TLS. n8n marque ainsi son cookie de session avec Secure et construit des URL https://.
• N8N_PORT=5678 est le port sur lequel n8n est à l’écoute à l’intérieur du conteneur. Ce n’est pas le port public : le proxy gère le port 443.
• WEBHOOK_URL=https://n8n.example.com/ est la variable la plus problématique. n8n affiche les adresses de webhook que vous copiez dans Stripe, GitHub ou tout autre appelant externe en les construisant à partir de ces valeurs. Si elle n’est pas définie ou si sa valeur est incorrecte, n8n utilise N8N_HOST:N8N_PORT et vous fournit https://n8n.example.com:5678/webhook/... ou, pire encore, http://localhost:5678/webhook/.... L’adresse est affichée sans erreur, semble plausible, mais elle est inaccessible depuis Internet. Les requêtes de l’appelant n’arrivent donc jamais, sans message explicite. Définissez cette variable sur l’URL de base publique exacte, avec la barre oblique finale, puis vérifiez que le nœud webhook affiche une URL sans port.

N8N_PROXY_HOPS=1 indique au serveur Express de n8n qu’un proxy se trouve devant lui. La limitation de débit et les fonctions qui lisent l’adresse IP du client voient ainsi l’adresse réelle, et non celle du proxy. Vous ne devez délibérément pas définir N8N_RUNNERS_ENABLED ici. Les task runners, qui exécutent la logique des nœuds Code de n8n dans un processus distinct du processus principal, étaient désactivés par défaut dans toute la série 1.x. La variable avait alors la valeur false par défaut et vous deviez la définir sur true. n8n 2.0 les active par défaut. Dans la série 2.x, ce guide indique donc que la variable est obsolète et la documentation de n8n précise qu’il n’est plus nécessaire de la définir.

Premier démarrage

docker compose up -d
docker compose ps
docker compose logs -f n8n

Un premier démarrage réussi se termine par une ligne Editor is now accessible via:, précédée d’une ligne n8n ready on ..., port 5678. docker compose ps doit afficher les deux conteneurs Up, avec postgres indiqué comme (healthy). Si n8n reste bloqué dans une boucle Restarting, consultez les journaux : le problème vient presque toujours de la connexion à la base de données ou des permissions du volume décrites ci-dessous.

TLS avec un reverse proxy

n8n utilise lui-même HTTP en clair sur le port 5678 ; un composant en amont termine la connexion HTTPS. Deux choix sont possibles.

Si vous exécutez déjà plusieurs conteneurs, placez n8n derrière un reverse proxy Traefik qui délivre automatiquement les certificats TLS. Quelques labels suffisent : Traefik demande et renouvelle le certificat pour vous.

Si cette application est la seule sur le serveur, un virtual host nginx avec un certificat Let’s Encrypt est plus simple. Utilisez la configuration TLS de Certbot et nginx pour Ubuntu 24.04 pour obtenir le certificat, puis utilisez ce server block :

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

Les en-têtes Upgrade et Connection "upgrade" sont obligatoires. n8n envoie les mises à jour en temps réel des exécutions à l’éditeur via un WebSocket. Sans ces deux lignes, la page de connexion se charge, puis reste bloquée avec un message indiquant que la connexion est perdue. proxy_read_timeout 3600 empêche l’interruption des exécutions longues après le délai par défaut de 60 secondes d’nginx. L’en-tête X-Forwarded-Proto $scheme complète N8N_PROXY_HOPS=1 : il indique à n8n que la requête d’origine utilisait HTTPS, même si le proxy le joint en HTTP en clair. n8n ne considère donc pas la connexion comme non sécurisée et ne rejette pas son propre cookie.

Votre premier workflow, pour le rendre opérationnel

Ouvrez https://n8n.example.com/, créez le compte propriétaire (section suivante), puis construisez le plus petit workflow permettant de vérifier que le chemin fonctionne : un webhook en entrée, un appel HTTP et une réponse en sortie.

1. Ajoutez un nœud Webhook. Définissez la méthode sur POST et un chemin tel que hello. Deux URL sont affichées : une Test URL et une Production URL. Elles sont à l’origine de nombreux signalements du type « mon webhook ne fonctionne pas ». La Test URL répond à un seul appel, et uniquement après avoir cliqué sur Listen for test event ; elle expire ensuite. La Production URL est enregistrée lorsque vous publiez le workflow et répond à partir de ce moment.
2. Ajoutez ensuite un nœud HTTP Request, configuré vers une API JSON publique quelconque. Une requête GET vers https://api.github.com/zen renvoie une chaîne sur une ligne, ce qui suffit.
3. Ajoutez un nœud Respond to Webhook, puis définissez l’option Respond du nœud Webhook sur « Using Respond to Webhook node » afin que l’appelant reçoive en retour la sortie du nœud HTTP.
4. Cliquez sur Publish (en haut à droite), puis appelez-le avec : curl -X POST https://n8n.example.com/webhook/hello. Vous devez récupérer la ligne zen : requête POST en entrée, appel API, réponse en sortie. C’est la structure de la plupart des automatisations réelles. Les anciens guides indiquent d’activer ici un bouton Active ; n8n 2.0 a remplacé ce bouton par Publish et Unpublish.

Une variante planifiée remplace le nœud Webhook par un Schedule Trigger et appelle à la place un endpoint de modèle. Un modèle auto-hébergé avec Ollama exécuté sur le même VPS constitue une solution simple pour créer un outil de synthèse nocturne.

Gestion des utilisateurs, pas une authentification basic

Les anciens guides n8n vous indiquent de définir N8N_BASIC_AUTH_ACTIVE=true. Ces variables ont été supprimées dans n8n 1.0 et ne servent plus à rien. Aujourd’hui, l’authentification repose sur le compte propriétaire : lors de la première ouverture de l’éditeur, n8n vous demande de créer un compte propriétaire avec une adresse e-mail et un mot de passe. Cette étape est obligatoire ; le mode anonyme n’existe pas. Créez immédiatement ce compte après le premier démarrage, avant de communiquer l’URL à qui que ce soit : entre docker compose up et l’envoi de ce premier formulaire, l’instance peut être revendiquée par la première personne qui y accède. Ajouter une couche d’authentification basic-auth au niveau du reverse proxy constitue une protection supplémentaire raisonnable, mais c’est un second verrou, pas le mécanisme d’authentification principal. Le compte propriétaire et tout le reste de ce guide fonctionnent avec l’édition communautaire gratuite ; si vous souhaitez ensuite ajouter d’autres utilisateurs avec des rôles détaillés ou mettre en place le SSO, consultez les fonctionnalités n8n qui nécessitent une licence payante avant de baser votre architecture dessus.

Sauvegardes : d’abord la clé de chiffrement, puis la base de données

Deux éléments doivent être sauvegardés, mais ils ne sont pas remplaçables au même titre.

La N8N_ENCRYPTION_KEY. Tous les identifiants que vous stockez dans n8n — jetons d’API, mots de passe de base de données, secrets OAuth — sont chiffrés au repos avec cette clé. Les workflows présents dans Postgres sont inutilisables sans elle : si vous restaurez la base de données sur une nouvelle machine avec une clé différente, n8n ne peut déchiffrer aucun identifiant. Il n’existe alors ni récupération ni réinitialisation possible. Votre fichier .env contient la clé ; copiez-le hors du serveur, idéalement dans une entrée de gestionnaire de mots de passe, le jour même où vous créez la clé. C’est la sauvegarde qui compte réellement.

La base de données Postgres, pour les workflows, l’historique des exécutions et les identifiants chiffrés eux-mêmes :

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

Exécutez cette commande selon une planification et copiez le dump hors de la machine. Pour restaurer l’instance sur un VPS vierge : démarrez une fois la stack afin que la base de données soit créée, arrêtez n8n, rechargez le dump avec psql, placez le même N8N_ENCRYPTION_KEY dans .env, puis démarrez n8n. La même clé et le dump permettent de retrouver une instance fonctionnelle ; une nouvelle clé produit des workflows qui ne peuvent utiliser aucun identifiant.

Mises à niveau : figer le tag

Le fichier Compose utilise volontairement n8nio/n8n:2.29.10 plutôt que latest. n8n publie une nouvelle version mineure presque chaque semaine et modifie parfois le schéma de la base de données ou le comportement des nœuds entre deux versions. Avec latest, un pull non supervisé peut donc récupérer une build qui migre votre base de données dès son démarrage. Figez une version, lisez les notes de version avant de la mettre à niveau — n8n y signale les changements incompatibles — puis effectuez la mise à niveau délibérément :

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

Les changements de version majeure sont les plus concernés. La branche 2.0, par exemple, a remplacé N8N_BLOCK_ENV_ACCESS_IN_NODE par true par défaut. Tout nœud Code qui lisait process.env perd donc silencieusement cet accès, jusqu’à ce que vous le rétablissiez avec false. Cette même version a commencé à appliquer des permissions strictes au fichier de paramètres, a activé les task runners par défaut et a remplacé le bouton Activate d’un workflow par Publish. Lisez la page consacrée aux changements incompatibles de la version 2.0 avant de franchir une limite de version majeure. n8n exécute automatiquement les migrations nécessaires de la base de données au démarrage. C’est précisément pourquoi le pg_dump préalable à la mise à niveau est obligatoire. Les identifiants étant chiffrés avec une clé stockée dans .env et les données étant stockées dans Postgres, les conteneurs sont remplaçables : effectuez la mise à niveau en les recréant, puis revenez en arrière en figeant le tag précédent et en restaurant le dump.

Modes d’échec et messages affichés

The requested webhook "POST hello" is not registered. Un 404 apparaît lorsque vous appelez un webhook dont le workflow n’est pas publié, ou lorsque vous appelez le chemin de test alors qu’aucun processus n’écoute. Les chemins de test (/webhook-test/...) répondent uniquement après avoir cliqué sur « Listen for test event » ; les chemins de production (/webhook/...) répondent uniquement une fois le workflow publié. Le message associé This webhook is not registered for GET requests. Did you mean to make a POST request? signifie que la méthode est incorrecte : le nœud attend POST, mais vous avez envoyé GET.

L’URL du webhook affiche :5678 ou localhost. Le nœud affiche https://n8n.example.com:5678/webhook/... ou http://localhost:5678/.... WEBHOOK_URL n’est pas défini ou sa valeur est incorrecte ; n8n a donc construit l’adresse à partir de N8N_HOST:N8N_PORT au lieu de votre base publique. Définissez WEBHOOK_URL=https://n8n.example.com/, recréez le conteneur avec docker compose up -d, et le port disparaîtra.

There was a problem loading init data dans le navigateur. L’éditeur est chargé, mais il ne peut pas joindre sa propre API backend. Derrière un proxy, cela indique presque toujours une valeur incorrecte pour N8N_HOST ou WEBHOOK_URL, un proxy auquel il manque les en-têtes WebSocket Upgrade, ou une valeur de N8N_PROTOCOL qui ne correspond pas à votre mode de connexion. Vérifiez les quatre variables exposées publiquement et assurez-vous que le proxy transmet Upgrade et Connection.

password authentication failed for user "n8n" dans les journaux, avec un redémarrage du conteneur. Le mot de passe envoyé par n8n ne correspond pas à celui avec lequel la base de données a été initialisée. Le piège est le suivant : Postgres ne lit POSTGRES_PASSWORD que lorsqu’il initialise un répertoire de données vide. Démarrez la stack une fois, puis modifiez POSTGRES_PASSWORD dans .env : le volume postgres_data existant conserve toujours l’ancien mot de passe. Rétablissez l’ancien mot de passe ou, si vous n’avez aucune donnée à conserver, docker compose down et docker volume rm le volume postgres, puis redémarrez avec une configuration vierge.

EACCES: permission denied, open '/home/node/.n8n/config' au démarrage. n8n s’exécute avec l’utilisateur node (UID 1000) et ne peut pas écrire dans son répertoire de configuration. Ce problème survient lorsque vous montez un répertoire de l’hôte (./n8n_data:/home/node/.n8n) appartenant à root. Utilisez le volume nommé indiqué plus haut ou, si vous utilisez absolument un bind mount, exécutez d’abord sudo chown -R 1000:1000 ./n8n_data.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Depuis la version 2.x, n8n impose par défaut 0600 sur ce fichier de paramètres et corrige lui-même ce mode au démarrage. Ce message indique qu’il l’a déjà corrigé, généralement après un bind mount ou après une restauration ayant recopié le fichier avec des permissions trop larges. Aucune action n’est nécessaire ; définissez N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false uniquement si votre système de fichiers ne peut réellement pas gérer les permissions.

Mismatching encryption keys, la ligne complète indique que la clé de chiffrement du fichier de paramètres /home/node/.n8n/config ne correspond pas à la N8N_ENCRYPTION_KEY définie dans votre environnement. La clé de votre environnement diffère de celle que n8n a enregistrée dans son volume de données lors d’une exécution précédente. Cela arrive le plus souvent lorsque n8n a généré une clé aléatoire lors d’un démarrage antérieur, parce que la variable n’était pas définie, puis que vous en avez défini une autre. Remettez la clé d’origine dans .env ou, uniquement si vous n’avez réellement aucun identifiant enregistré à conserver, supprimez le fichier config à l’intérieur du volume n8n_data et laissez n8n le régénérer. Les identifiants existants deviendront alors illisibles.

Bannière de connexion indiquant un problème avec les cookies sécurisés : Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. Vous avez défini N8N_PROTOCOL=https, mais vous avez accédé à n8n en HTTP simple, généralement en utilisant directement l’adresse IP et le port au lieu du proxy HTTPS. Accédez-y via https://n8n.example.com/. Si vous ne pouvez réellement pas utiliser HTTPS, définissez N8N_SECURE_COOKIE=false, mais jamais sur un serveur exposé à Internet.

Pour intégrer un modèle de langage dans ces workflows, consultez créer des workflows d’IA avec Claude et n8n.

FAQ

Dois-je utiliser SQLite ou Postgres pour n8n ?

SQLite (la valeur par défaut) convient pour tester n8n et pour une instance personnelle qui exécute un workflow à la fois. Passez à Postgres pour tout ce dont vous dépendez : le verrou d’écriture unique de SQLite provoque des database is locked en cas de concurrence, et Postgres se sauvegarde proprement avec pg_dump. La migration ultérieure est manuelle. Si le serveur est important, commencez avec Postgres.

Pourquoi mes webhooks n8n ne se déclenchent-ils jamais ?

Dans presque tous les cas, c’est WEBHOOK_URL. Si la valeur est absente ou incorrecte, n8n affiche des adresses de webhook construites à partir de N8N_HOST:N8N_PORT, souvent avec un :5678 ou un localhost, qui semblent valides mais sont inaccessibles depuis Internet. Les requêtes de l’appelant n’arrivent donc jamais. Définissez WEBHOOK_URL=https://n8n.example.com/ et vérifiez que le nœud affiche une URL sans port. La deuxième cause est l’appel de l’URL de production d’un workflow que vous n’avez pas publié, ce qui renvoie The requested webhook ... is not registered.

Que dois-je sauvegarder dans n8n ?

Deux éléments. D’abord, le N8N_ENCRYPTION_KEY de votre fichier .env, car chaque identifiant enregistré est chiffré avec cette valeur. Si vous la perdez, ces identifiants deviennent définitivement impossibles à déchiffrer. Copiez-la hors du serveur le jour où vous la créez. Ensuite, un pg_dump de la base de données Postgres contenant les workflows, l’historique et les identifiants. Une restauration nécessite les deux éléments : la même clé et le dump.

Comment placer n8n derrière HTTPS ?

n8n fournit du HTTP en clair sur le port 5678 ; un reverse proxy placé devant assure la terminaison TLS. Liez n8n à 127.0.0.1:5678 afin que seul le proxy puisse y accéder, puis utilisez Traefik avec des certificats automatiques ou nginx avec un certificat Let's Encrypt. Définissez N8N_PROTOCOL=https et WEBHOOK_URL=https://your-host/, et vérifiez que le proxy transmet les en-têtes Upgrade du WebSocket. Sinon, l’éditeur se bloque.

Comment mettre n8n à niveau en toute sécurité ?

Verrouillez un tag d’image précis au lieu de latest, effectuez d’abord un pg_dump, car n8n exécute automatiquement les migrations au démarrage, consultez les notes de version pour repérer les changements incompatibles, puis mettez à jour le tag et exécutez docker compose pull n8n && docker compose up -d n8n. Le conteneur est jetable. Pour revenir en arrière, verrouillez le tag précédent et restaurez le dump créé avant la mise à niveau.