Les variables d'environnement les plus importantes expliquées (N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE ...)

Quiconque héberge soi-même une instance n8n configure les réglages centraux tels que l'accessibilité, le fuseau horaire, la base de données et la sécurité non pas via l'interface, mais via des variables d'environnement définies au démarrage du conteneur ou du processus. Parmi les plus de cent variables documentées, seule une poignée est vraiment déterminante pour la plupart des installations auto-hébergées allemandes, par exemple N8N_HOST pour le nom d'hôte, WEBHOOK_URL pour l'accès public derrière un reverse proxy, ou GENERIC_TIMEZONE afin que les workflows programmés se déclenchent à la bonne heure. Cet article classe les variables les plus pertinentes en pratique par thème et montre à chaque fois un exemple d'utilisation. État : juillet 2026.

Configuration de base : accessibilité, URL et fuseau horaire

Ces variables déterminent comment n8n est accessible en interne et en externe, et dans quel fuseau horaire s'exécutent les workflows programmés.

• N8N_HOST : Détermine le nom d'hôte sous lequel n8n est accessible en interne, la valeur par défaut est localhost, pour un serveur avec son propre domaine par exemple n8n.votreentreprise.de.
• N8N_PORT : Le port sur lequel le processus n8n écoute, valeur par défaut 5678, pertinent lorsque plusieurs services fonctionnent en parallèle sur le même serveur.
• N8N_PROTOCOL : Détermine si n8n est contacté en interne via http ou https, la valeur par défaut est http, derrière un reverse proxy qui termine le TLS, cela reste généralement en http en interne.
• N8N_EDITOR_BASE_URL : L'URL publique sous laquelle les utilisateurs accèdent à l'éditeur, également utilisée pour les liens par e-mail et les redirections SAML, exemple https://n8n.votreentreprise.de.
• WEBHOOK_URL : Définie manuellement lorsque n8n fonctionne derrière un reverse proxy, afin que les webhooks entrants utilisent la bonne adresse publique, exemple https://n8n.votreentreprise.de/.
• GENERIC_TIMEZONE : Le fuseau horaire de l'instance n8n, valeur par défaut America/New_York, pour les installations allemandes il faut ici pratiquement toujours indiquer Europe/Berlin, sinon les déclencheurs cron et planifiés se déclenchent à la mauvaise heure.

Sécurité et protection des données

En particulier pour les entreprises pour qui la souveraineté allemande des données et le contrôle de leurs propres données sont importants, il vaut la peine d'examiner de près les variables liées à la sécurité.

• N8N_ENCRYPTION_KEY : La clé avec laquelle n8n chiffre les identifiants dans la base de données, générée aléatoirement si non spécifiée, devrait être fixée définitivement et conservée de manière sécurisée dans les installations en production, car les identifiants enregistrés ne peuvent sinon plus être déchiffrés après une reconstruction.
• N8N_SECURE_COOKIE : Garantit que les cookies ne sont transmis que via HTTPS, valeur par défaut true, ne devrait être mise à false que pour un fonctionnement de test purement HTTP sans TLS.
• N8N_BLOCK_ENV_ACCESS_IN_NODE : Empêche les utilisateurs d'accéder aux variables d'environnement du serveur via des expressions ou le nœud Code, valeur par défaut false, true est recommandé pour les instances multi-utilisateurs avec des identifiants sensibles.
• N8N_DIAGNOSTICS_ENABLED : Contrôle si n8n envoie des données de télémétrie anonymisées au fabricant, valeur par défaut true, quiconque souhaite une souveraineté maximale des données mettra false ici.

Base de données et exploitation

Pour une exploitation en production, la plupart des installations passent de la base de données SQLite fournie à PostgreSQL, ce qui se configure via des variables dédiées.

• DB_TYPE : Détermine la base de données utilisée, valeur par défaut sqlite, postgresdb est la valeur courante pour les environnements de production avec plusieurs utilisateurs simultanés.
• DB_POSTGRESDB_HOST : Le nom d'hôte du serveur PostgreSQL, valeur par défaut localhost, pour une base de données séparée par exemple le nom d'hôte interne du conteneur de base de données.
• DB_POSTGRESDB_DATABASE : Le nom de la base de données PostgreSQL, valeur par défaut n8n, peut être adapté pour plusieurs instances sur le même serveur.
• DB_POSTGRESDB_USER / DB_POSTGRESDB_PASSWORD : Identifiants pour la connexion PostgreSQL, sans valeur par défaut pour le mot de passe, ne devraient pas, comme tout mot de passe de base de données, se retrouver en clair dans le dépôt, mais être gérés via un secret.
• N8N_PROXY_HOPS : Indique derrière combien de reverse proxies n8n fonctionne, valeur par défaut 0, typiquement 1 avec un seul Nginx ou Traefik devant, afin que n8n détermine correctement l'adresse IP réelle du client.

La plupart des problèmes lors de l'auto-hébergement de n8n ne proviennent pas de variables manquantes, mais d'URL mal définies ou d'un fuseau horaire qui ne correspond pas à l'emplacement du serveur. Quiconque souhaite faire installer, sécuriser ou migrer sa propre instance n8n vers Postgres trouve auprès des services n8n de NordFlux un accompagnement pour la mise en place et la configuration.

Questions fréquentes sur les variables d'environnement n8n

Où définir les variables d'environnement dans n8n ?

Cela dépend du type d'installation. Avec Docker, cela se fait via des indicateurs -e ou un fichier .env dans le docker-compose.yml, avec une installation classique en tant que variables d'environnement système définies avant le démarrage du processus n8n.

Que se passe-t-il si je ne définis pas N8N_ENCRYPTION_KEY ?

n8n génère alors automatiquement une clé aléatoire au premier démarrage. Si celle-ci est perdue, par exemple lors d'une reconstruction du conteneur sans stockage persistant, les identifiants déjà enregistrés ne peuvent plus être déchiffrés.

Dois-je toujours définir WEBHOOK_URL ?

Seulement si n8n fonctionne derrière un reverse proxy ou sous une adresse publique différente de celle configurée en interne. En cas d'accès direct via N8N_HOST et N8N_PORT, la variable n'est généralement pas nécessaire.

Puis-je modifier les variables d'environnement ultérieurement ?

Oui, la plupart des variables ne prennent effet qu'après un redémarrage du processus n8n. Les workflows en cours et les données déjà enregistrées n'en sont pas affectés, tant que la connexion à la base de données ne change pas.

Plus de détails sur toutes les variables documentées se trouvent dans la documentation n8n sur les variables d'environnement ainsi que spécifiquement sur la configuration de la base de données.