Self-hosted n8n with Docker: what production requires

Installing a self-hosted n8n with Docker takes a few commands, which the n8n documentation on Docker Compose gives step by step. It nevertheless opens with a warning: the vendor recommends self-hosting to experienced users, because a mistake can cost data, security or downtime. Between the instance that starts and the one you trust with real processes, there are decisions left to make.

We have made several of them for our own server, which runs a dozen services in Docker containers, behind a Traefik router. n8n runs our production workflows there, including an expense-entry agent on Telegram and the one that assigns an internal identifier to each new property in the CRM of Palmora Property, a real estate portal that we operate. This guide puts the vendor’s documentation and our own operation side by side.

Docker or Docker Compose?

The documentation page that installs n8n with Docker alone is flagged as outdated by the vendor itself, which points to Docker Compose: a single file describes the containers, their volumes and their variables, and it can be versioned like code.

The vendor’s template sets up two containers, n8n and a proxy, and keeps the data in a volume:

Two additions to the template: keep the secrets (database password, encryption key) in an environment file that does not go into the repository, and replace the image that follows the latest version with a specific version.

SQLite or PostgreSQL?

Without any setting, n8n stores its workflows, its credentials and the execution history in a SQLite database, a file kept in its volume. The documentation for installation with Docker explains the switch to PostgreSQL: the DB_TYPE=postgresdb variable and the DB_POSTGRESDB_* variables (host, database, user, password). It recommends keeping the /home/node/.n8n folder even with PostgreSQL: it contains other important data, including the encryption keys and the instance’s logs.

SQLite is enough to try n8n on a single instance. As soon as the work is spread across several processes, the queue mode documentation advises against SQLite, and does not support a distributed system that would rely on it. We recommend PostgreSQL as soon as an instance carries production processes: the database is backed up with its own tools, as we detail in our guide to backing up your own server, and moving to queue mode, if it ever comes, will not require changing databases.

The encryption key, the secret you must never lose

n8n encrypts the credentials you entrust to it (API keys, passwords of connected services) before saving them in the database. According to the documentation on the encryption key, it creates a random key on first start and keeps it in its data folder; you can set your own with the N8N_ENCRYPTION_KEY variable, as long as the key is not already in the settings file. So set it before the first start, and keep a copy in a secrets manager, off the server.

Which variables should you set before going into production?

The vendor’s template sets some of them. Here are those to check before the first real process, according to n8n’s documentation on webhooks behind a proxy, the time zone and execution data.

How do you update n8n without breaking production?

According to its Docker Compose documentation, n8n releases a new minor version most weeks: the stable version is for production, the beta is more recent and may be unstable. An image that follows the latest version can move you up several versions at once, without you having decided it. We recommend four steps:

1. 01Pin a specific version.

   The Compose file sets the version number, rather than following the latest.

2. 02Read the release notes.

   Moving to a new major version needs the most attention: 2.0, for example, disabled the Execute Command node by default.

3. 03Back up the database and check the key.

   A backup made just before the update lets you go back.

4. 04Upgrade, then check.

   The documentation chains docker compose pull, docker compose down, then docker compose up -d. Then open a critical workflow and watch its next execution.

And never a server-wide cleanup at that point: a command of that kind deleted the containers of ten services on our server in July 2026.

Should you move to queue mode?

Queue mode spreads executions across several workers, through a queue held by Redis. According to its documentation, it requires EXECUTIONS_MODE=queue and the same encryption key on every process and, if your workflows have to keep files, external S3-type storage: this mode does not support storing them on the server’s disk.

Start with a single, well-configured instance, and only split it up after measuring what slows things down.

What does not belong in n8n?

With Docker, the Execute Command node runs its commands inside n8n’s container, not on the server, and it has been disabled by default since version 2.0. The container only sees the folders that have been mounted into it. Giving it access to the server, for example to the Docker engine, would hand that power to every workflow and to everyone who can edit one.

Hence the rule we recommend: tasks that need the server’s tools (backups, cleanups, scripts that publish a site) go in the server’s scheduler or in continuous integration, not in n8n.

n8n keeps what it does best: linking services through their APIs.

Telemetry: what goes to the vendor

According to its privacy page, n8n never receives your workflows’ data when you host it yourself. Its telemetry, on by default and presented as pseudonymous (tied to a code, not to your name), includes in particular a truncated IP address, the main domain of the addresses called by HTTP Request nodes and of webhook calls, with no subdomain or path, and information about the instance, its usage and its errors. The telemetry page adds the number of executions and an instance pulse every six hours.

There is no switch in the interface: everything is turned off through environment variables, gathered in the guide to isolating an instance. With a paid licence, the instance keeps reporting its usage volumes and its licence identifier, and this cannot be turned off. Following this guide also turns off the announcement of new versions in the interface: watching the release notes becomes your job.

GDPR: your responsibility

The privacy page puts it bluntly:

The same page makes an exception for telemetry: n8n is the controller of the usage and diagnostic data your instance sends it.

Four points therefore call for a decision on your part.

• The execution history keeps personal data. To erase one person’s data, n8n says to delete the executions that concern them and recommends configuring their purge; our guide to monitoring n8n in production details what it keeps and for how long.
• Masking execution data is reserved for the Enterprise edition when self-hosting, according to its documentation: without it, the history remains readable by anyone with access.
• Every service called receives data. An AI model API or an emailing tool is one more processor, with its own contract.
• The register and the contracts. The processing goes into your record of processing activities, and the host of your server is a processor, to be bound by a contract compliant with Article 28 of the GDPR. The CNIL, France’s data protection authority, advises against “using cloud services without a guarantee as to the actual geographical location of the data” in its fact sheet on subcontracting.

This guide says where to look; it does not replace legal advice on your processing.

Honest limits

• Self-hosting moves the cost, it does not remove it: the server, backups, frequent updates and someone to keep watch.
• No availability guarantee from a vendor: at night, your alert is what warns you, or nobody does.
• The Community edition includes neither SSO nor workflow sharing: we detail what n8n’s licence allows.

Where to start

Start with an inventory: the processes n8n will carry, the data they touch, and who receives the alerts. Then, in order: the versioned Compose file and the key kept off the server, the database, the variables, the decision on telemetry, and a first tested restore before the first process goes into production.

If n8n is only one of the tools to install, our guide to the infrastructure foundation common to your projects sets the framework; if you are still unsure about hosting it yourself, read our comparison of n8n, Make and Zapier. For a server that is installed, backed up and monitored, our Leaving SaaS offer installs up to five tools, with managed services as an option; if it is the processes themselves that need building, that is our automation offer.

Frequently asked questions

Sources

1. N8n documentation on Docker Compose (new tab)docs.n8n.io
2. Installs n8n with Docker alone (new tab)docs.n8n.io
3. The queue mode documentation (new tab)docs.n8n.io
4. The documentation on the encryption key (new tab)docs.n8n.io
5. Webhooks behind a proxy (new tab)docs.n8n.io
6. The time zone (new tab)docs.n8n.io
7. Execution data (new tab)docs.n8n.io
8. The Execute Command node (new tab)docs.n8n.io
9. Its privacy page (new tab)docs.n8n.io
10. The telemetry page (new tab)docs.n8n.io
11. The guide to isolating an instance (new tab)docs.n8n.io
12. Its documentation (new tab)docs.n8n.io
13. Record of processing activities (new tab)cnil.fr
14. Its fact sheet on subcontracting (new tab)cnil.fr