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 manière dont n8n se présente au monde extérieur. Une mauvaise configuration de ces variables est le principal sujet des demandes d’assistance concernant n8n.

• N8N_HOST est le nom d’hôte public, n8n.example.com. Si vous le laissez à sa valeur par défaut, localhost, derrière un proxy, l’éditeur tente 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 donc son cookie de session avec Secure et construit des URL en https://.
• N8N_PORT=5678 est le port sur lequel n8n é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 génère les adresses des webhooks 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 reste inaccessible depuis Internet. Les requêtes de l’appelant n’arrivent donc jamais, sans message d’erreur visible. Définissez cette variable avec l’URL de base publique exacte, barre oblique finale comprise, 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 seul proxy se trouve devant lui. La limitation de débit et toutes les fonctions qui lisent l’adresse IP du client voient ainsi la véritable adresse, et non celle du proxy. Vous ne devez volontairement pas définir N8N_RUNNERS_ENABLED ici. Les task runners, qui exécutent la logique des nœuds Code de n8n dans un processus séparé et isolé, sont utilisés par défaut depuis 1.69 et sont obligatoires à partir de la branche 2.x ciblée par ce guide. L’ancienne activation explicite est donc obsolète. Si vous définissez quand même cette variable, n8n se contente de journaliser un message vous demandant de la supprimer.

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 workflow minimal qui vérifie le fonctionnement du chemin : un webhook en entrée, un appel HTTP, 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 s’affichent : une Test URL et une Production URL. Elles expliquent une grande partie des 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 répond lorsque le workflow est Active.
2. Ajoutez ensuite un nœud HTTP Request, dirigé vers n’importe quelle API JSON publique. 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 la sortie du nœud HTTP.
4. Activez le workflow avec Active (en haut à droite), puis appelez-le : curl -X POST https://n8n.example.com/webhook/hello. Vous devriez recevoir la ligne zen : la requête POST entre, l’appel API est effectué et la réponse ressort. C’est la structure de la plupart des automatisations réelles.

Dans une variante planifiée, remplacez le nœud Webhook par un Schedule Trigger et appelez plutôt un endpoint de modèle. Un modèle auto-hébergé avec Ollama exécuté sur le même VPS permet de créer facilement un résumé 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 : verrouiller le tag

Le fichier Compose verrouille n8nio/n8n:2.29.10 au lieu de latest intentionnellement. n8n publie une nouvelle version mineure presque toutes les semaines et modifie parfois le schéma de la base de données ou le comportement des nodes entre deux versions. Ainsi, latest signifie qu’un pull sans supervision peut vous fournir une build qui migre votre base de données dès son démarrage. Verrouillez une version, lisez les notes de version avant de la mettre à niveau — n8n y signale les changements incompatibles — puis effectuez la mise à niveau volontairement :

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 défini N8N_BLOCK_ENV_ACCESS_IN_NODE sur true par défaut. Tout Code node qui lisait process.env perd donc silencieusement son accès jusqu’à ce que vous le redéfinissiez sur false. Cette même version a également commencé à imposer des permissions strictes sur le fichier de paramètres. Lisez la page des 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 credentials étant chiffrés avec une clé stockée dans .env et les données étant stockées dans Postgres, les conteneurs sont remplaçables : mettez à niveau en les recréant, puis revenez à la version précédente en verrouillant l’ancien tag et en restaurant le dump.

Modes de défaillance et messages affichés

The requested webhook "POST hello" is not registered. Un statut 404 apparaît si vous appelez un webhook dont le workflow n’est pas Active, ou si vous appelez le chemin de test alors que personne ne l’é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 lorsque le workflow est activé. Le statut 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 est incorrect. n8n a donc construit l’adresse à partir de N8N_HOST:N8N_PORT au lieu de votre adresse 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 s’est chargé, mais il ne peut pas joindre sa propre API backend. Derrière un proxy, la cause est presque toujours un N8N_HOST ou un WEBHOOK_URL incorrect, un proxy qui ne transmet pas les en-têtes Upgrade de WebSocket, ou un 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 logs, avec un redémarrage du conteneur. Le mot de passe envoyé par n8n ne correspond pas à celui utilisé lors de l’initialisation de la base de données. 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 première 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 installation 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 souvent lorsque vous montez un répertoire de l’hôte (./n8n_data:/home/node/.n8n) appartenant à root. Utilisez le named volume indiqué plus haut ou, si vous devez utiliser 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 les permissions au démarrage. Ce message signifie qu’il a déjà corrigé le mode, généralement après un bind mount ou après une restauration qui a recréé le fichier avec des permissions trop ouvertes. Aucune action n’est nécessaire. Définissez N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false uniquement si votre système de fichiers ne prend réellement pas en charge 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 à N8N_ENCRYPTION_KEY dans votre environnement. La clé définie dans votre environnement diffère de celle que n8n a écrite dans son volume de données lors d’une exécution précédente. Cela arrive le plus souvent parce que n8n a généré une clé aléatoire lors d’un démarrage précédent, lorsque la variable n’était pas définie, puis que vous en avez défini une autre. Restaurez 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 que les cookies sécurisés posent problème : 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 non chiffré, 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 IA avec Claude et n8n.

FAQ

SQLite ou Postgres pour n8n ?

SQLite (la base 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 database is locked en cas de concurrence, et Postgres se sauvegarde proprement avec pg_dump. La migration ultérieure est manuelle. Si cette instance est importante, commencez avec Postgres.

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

Dans presque tous les cas, c’est WEBHOOK_URL. Lorsqu’elle n’est pas définie ou qu’elle est incorrecte, n8n affiche des adresses de webhook construites à partir de N8N_HOST:N8N_PORT, qui contiennent souvent :5678 ou localhost. Elles 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. L’autre cause fréquente est l’appel d’un webhook dont le workflow n’est pas activé. Cela 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 celui-ci. Si vous le perdez, ces identifiants deviennent définitivement impossibles à déchiffrer. Copiez-le hors du serveur le jour où vous le 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 non chiffré 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é ?

Épinglez 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 disposable. Pour revenir en arrière, épinglez le tag précédent et restaurez le dump créé avant la mise à niveau.