The most important environment variables explained (N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE ...)

Anyone who self-hosts an n8n instance configures central settings such as accessibility, timezone, database and security not through the interface, but through environment variables that are set when the container or process starts. Of the more than one hundred documented variables, only a handful are truly decisive for most German self-hosting setups, for example N8N_HOST for the hostname, WEBHOOK_URL for public access behind a reverse proxy, or GENERIC_TIMEZONE so that time-triggered workflows fire at the correct time. This article organizes the most practically relevant variables by topic area and shows an example of use for each. As of: July 2026.

Basic configuration: accessibility, URL and timezone

These variables determine how n8n is reachable internally and externally, and in which timezone time-triggered workflows run.

• N8N_HOST: Determines the hostname under which n8n is reachable internally, the default value is localhost, for a server with its own domain for example n8n.yourcompany.com.
• N8N_PORT: The port on which the n8n process listens, default value 5678, relevant when several services run in parallel on the same server.
• N8N_PROTOCOL: Determines whether n8n is addressed internally via http or https, the default is http, behind a TLS-terminating reverse proxy it usually stays at http internally.
• N8N_EDITOR_BASE_URL: The public URL under which users reach the editor, also used for email links and SAML redirects, example https://n8n.yourcompany.com.
• WEBHOOK_URL: Set manually when n8n runs behind a reverse proxy, so that incoming webhooks use the correct public address, example https://n8n.yourcompany.com/.
• GENERIC_TIMEZONE: The timezone of the n8n instance, default value is America/New_York, for German setups this should practically always be Europe/Berlin, otherwise cron and schedule triggers fire at the wrong time.

Security and data protection

Especially for companies for whom German data sovereignty and control over their own data are important, it is worth taking a close look at the security-relevant variables.

• N8N_ENCRYPTION_KEY: The key with which n8n encrypts credentials in the database, generated randomly if not specified, should be set permanently and stored securely in production setups, since stored credentials can otherwise no longer be decrypted after a rebuild.
• N8N_SECURE_COOKIE: Ensures that cookies are only transmitted over HTTPS, default value is true, should only be set to false for pure HTTP test operation without TLS.
• N8N_BLOCK_ENV_ACCESS_IN_NODE: Prevents users from accessing the server's environment variables via expressions or the Code node, default value is false, true is recommended for multi-user instances with sensitive credentials.
• N8N_DIAGNOSTICS_ENABLED: Controls whether n8n sends anonymized telemetry data to the manufacturer, default value is true, anyone who wants maximum data sovereignty sets this to false.

Database and operation

For production operation, most setups switch from the bundled SQLite database to PostgreSQL, which is configured via its own variables.

• DB_TYPE: Determines the database used, default value is sqlite, postgresdb is the common value for production environments with multiple simultaneous users.
• DB_POSTGRESDB_HOST: The hostname of the PostgreSQL server, default value is localhost, for a separate database for example the internal hostname of the database container.
• DB_POSTGRESDB_DATABASE: The name of the PostgreSQL database, default value is n8n, can be adjusted for multiple instances on the same server.
• DB_POSTGRESDB_USER / DB_POSTGRESDB_PASSWORD: Credentials for the PostgreSQL connection, no default value for the password, should not end up in plain text in the repository like any database password, but be managed via a secret.
• N8N_PROXY_HOPS: Indicates how many reverse proxies n8n runs behind, default value is 0, typically 1 with a single Nginx or Traefik in front, so that n8n correctly determines the actual client IP.

Most problems with n8n self-hosting do not arise from missing variables, but from incorrectly set URLs or a timezone that does not match the server location. Anyone who wants to set up, secure, or migrate their own n8n instance to Postgres will find at the n8n services from NordFlux support for setup and configuration.

Frequently asked questions about n8n environment variables

Where do I set environment variables in n8n?

This depends on the installation type. With Docker this happens via -e flags or an .env file in the docker-compose.yml, with a classic installation as system environment variables that are set before the n8n process starts.

What happens if I don't set N8N_ENCRYPTION_KEY?

n8n then automatically generates a random key on first start. If this is lost, for example during a container rebuild without persistent storage, credentials already stored can no longer be decrypted.

Do I always have to set WEBHOOK_URL?

Only if n8n runs behind a reverse proxy or under a different public address than configured internally. With direct access via N8N_HOST and N8N_PORT, the variable is usually not necessary.

Can I change environment variables afterwards?

Yes, most variables only take effect after a restart of the n8n process. Running workflows and already stored data remain unaffected, as long as the database connection does not change.

Further details on all documented variables can be found in the n8n documentation on environment variables as well as specifically on database configuration.