n8n Self-Hosted: A Practical Guide to Docker Deployment

Running n8n self-hosted gives you the full workflow automation engine on infrastructure you control, without a per-execution bill and without handing your credentials to someone else's cloud. The default install is deceptively simple, which is exactly the problem. A quick docker run will start n8n, but it stores everything in a throwaway SQLite file and generates a secret it never tells you about. Restart the container the wrong way and your workflows and saved credentials are gone.

This guide covers what n8n actually is, whether it is free, and how to run it in a way that survives restarts and traffic. We walk through the official Docker image, why production needs PostgreSQL, the one environment variable that protects your stored credentials, and how queue mode scales workers. Then we cover an honest path to deploy n8n self-hosted on a PaaS so you skip the server maintenance without giving up control.

The short answer: n8n self-hosted means running the open community edition of n8n on infrastructure you control instead of paying for the hosted cloud. You run the official Docker image, attach a PostgreSQL database, set a fixed N8N_ENCRYPTION_KEY, and add persistent storage. Self-hosting the community edition is free under the Sustainable Use License. Cloud hosting and some enterprise features are paid.

What is n8n?

n8n is a workflow automation tool. You build automations visually by wiring together nodes, where each node calls an app, an API, a database, or a piece of custom code. A workflow might watch an inbox, extract data with an HTTP request, transform it with a function node, and write the result to a spreadsheet, all without you writing a backend service to glue those systems together.

n8n is a fair-code workflow automation tool that connects apps, APIs, and databases through visual nodes. It is source-available under the Sustainable Use License, which lets you self-host it for free for internal business purposes and modify the source to fit your needs.

The distinction that matters for hosting is the license. n8n is not classic open source under an OSI-approved license, and it is not proprietary either. It sits in between, which is why you can legally run the community edition on your own machines at no cost. For a broader look at running containerized tools yourself, see our guide to self-hosting applications with Docker.

Is n8n free?

Yes, with a precise boundary. Self-hosting the n8n community edition is free. You download the image, run it, and pay nothing to n8n for the software. What you pay for is the compute, storage, and bandwidth wherever you run it, which is true of anything you host.

The paid side has two parts. n8n Cloud is a hosted subscription where the vendor runs and maintains the instance for you. Separately, a set of enterprise features (advanced permissions, SSO, environments, and log streaming among them) sits behind a paid license even on self-hosted installs. For most individuals and small teams automating internal work, the free community edition is complete enough to run in production. You can read the exact terms on the official n8n Sustainable Use License page.

Running n8n with Docker

The official n8n Docker image is the standard way to self-host. It is published, versioned, and used by the maintainers themselves, so you are not maintaining a custom build. The n8n Docker installation docs are the reference, and the short version looks like this.

docker run -d --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

That command works, and it is also the wrong way to run n8n for anything real. By default n8n stores workflows and credentials in a SQLite file inside the container, and it auto-generates an encryption key it saves to disk. If the volume is not persisted, or you move to a second replica, both the database and the key disappear. Three things turn this from a demo into a production setup: a real database, a fixed encryption key, and persistent storage.

Why n8n needs PostgreSQL in production

SQLite is fine on a laptop and fragile everywhere else. It is a single file, it does not handle concurrent writers well, and it does not survive the container lifecycle unless you are careful with volumes. The moment you want reliable backups, point-in-time recovery, or more than one n8n process touching the same data, SQLite becomes the bottleneck. n8n supports PostgreSQL as its production database for exactly this reason.

You point n8n at PostgreSQL with a handful of environment variables. PostgreSQL then holds your workflows, execution history, and encrypted credentials in a system built for concurrent access and proper backups. PostgreSQL's own continuous archiving and point-in-time recovery is what lets you restore an n8n instance to the exact moment before a bad change, something SQLite cannot offer. If you need a database first, our guide to free PostgreSQL hosting covers your options.

Here is a fuller environment list for a Docker or Compose setup that uses PostgreSQL:

docker run -d --name n8n \
  -p 5678:5678 \
  -e DB_TYPE=postgresdb \
  -e DB_POSTGRESDB_HOST=your-postgres-host \
  -e DB_POSTGRESDB_PORT=5432 \
  -e DB_POSTGRESDB_DATABASE=n8n \
  -e DB_POSTGRESDB_USER=n8n \
  -e DB_POSTGRESDB_PASSWORD=super-secret-password \
  -e N8N_ENCRYPTION_KEY=a-long-random-string \
  -e WEBHOOK_URL=https://n8n.example.com/ \
  -e N8N_HOST=n8n.example.com \
  -e N8N_PROTOCOL=https \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

The encryption key that protects your credentials

The most common way people lose an n8n instance is the encryption key. n8n encrypts every stored credential (API tokens, database passwords, OAuth secrets) before writing it to the database. The key for that encryption lives in N8N_ENCRYPTION_KEY.

The n8n encryption key (N8N_ENCRYPTION_KEY) is the secret n8n uses to encrypt stored credentials at rest. If you do not set it explicitly, n8n generates a random key on first run and saves it to disk. Lose that key and every saved credential in your database becomes permanently unreadable.

The rule is simple: set this value yourself, to a long random string, and store it somewhere safe before your first run. If you let n8n generate it, the key ends up in the container's /home/node/.n8n folder, and it will not match if you rebuild the container, move hosts, or run a second replica pointed at the same database. Set it once as an environment variable and every instance decrypts the same credentials.

WEBHOOK_URL is the other value people miss. n8n needs to know its own public HTTPS address so the URLs it hands to external services (for triggers and callbacks) actually reach it. Behind a proxy or on a platform that terminates TLS for you, set WEBHOOK_URL to the public address, or your webhook nodes will generate links that point nowhere.

Queue mode for scaling workers

A single n8n container runs your triggers and your executions in the same process. That is fine until a heavy workflow or a burst of webhooks starts blocking everything else. Queue mode separates the two jobs so you can add capacity.

Queue mode is an n8n execution model where a main process receives triggers and pushes jobs onto a Redis queue, and separate worker processes pull jobs and run them. It lets you scale execution horizontally by adding workers, so one slow workflow does not stall the rest.

You enable it with EXECUTIONS_MODE=queue and point n8n at a Redis instance with QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT. Then you run one or more worker containers alongside the main instance. Redis here is the job broker, not your data store, so it complements PostgreSQL rather than replacing it. Most small deployments never need queue mode. Reach for it when execution volume climbs or when a single process can no longer keep up.

Deploying n8n self-hosted on Out Plane

Running your own server means you also own the operating system patches, the TLS certificates, the database backups, and the 2 a.m. pager. A PaaS removes that layer while keeping you in control of the container and its data. Out Plane is that kind of platform: you give it a Dockerfile, it builds the image and runs your app, with a managed PostgreSQL database alongside and HTTPS handled automatically. If the model is new to you, start with what a PaaS is.

Here is the honest path to run n8n self-hosted on Out Plane:

1. Create the app from a Dockerfile. A one-line Dockerfile (FROM docker.n8n.io/n8nio/n8n:latest) is enough. Out Plane runs the build for you and starts the container. Our Docker hosting guide explains how the build step works in more detail.
2. Attach a managed PostgreSQL database. Provision one in the console, then set DB_TYPE=postgresdb and the DB_POSTGRESDB_* variables from the database's connection details. You get automated backups, point-in-time recovery, connection pooling, and read replicas without configuring any of it.
3. Set the encryption key. Add N8N_ENCRYPTION_KEY as an environment variable with your own long random string. Because it lives in the app config rather than a container file, it stays consistent across restarts and redeploys.
4. Expose the port and get a URL. n8n listens on 5678. Out Plane gives the app automatic HTTPS and a public address in the form n8n-5678-yourteam.outplane.app. Set WEBHOOK_URL and N8N_HOST to that address so webhooks resolve correctly.
5. Add a persistent volume for /home/node/.n8n if you want binary data and local files to survive restarts, since your primary state already lives in PostgreSQL.

For queue mode, deploy Redis as a second container app with its own persistent volume, then point n8n at it. The managed database on Out Plane is PostgreSQL only, so Redis, like any non-Postgres engine, runs as a self-hosted container rather than a managed service. You can also pick an EU region (Nuremberg or Helsinki) so your workflow data and credentials stay in Europe. That is a data residency choice about where bytes live, not a legal certification.

n8n alternatives and hosting options

If you searched for n8n alternatives, you are usually choosing between two different things: a different tool, or a different way to host the same tool. For most people it is the second one. The tool is fine. The question is who runs the infrastructure.

As for other automation tools, the category is crowded. There are hosted no-code automation services aimed at non-technical users, other source-available workflow engines you can self-host, and lighter task-runners for simple jobs. n8n's advantage is the combination of a visual builder, a large node library, custom-code nodes, and a license that lets you self-host for free. If that combination fits, the real decision is hosting, not the tool.

Frequently Asked Questions

Is n8n really free to self-host?

Yes. The n8n community edition is free to self-host under the Sustainable Use License, which permits internal business use at no cost. You pay only for the servers or platform you run it on. n8n Cloud and a set of enterprise features (such as SSO and advanced permissions) are the paid parts.

Why does n8n need PostgreSQL instead of SQLite?

SQLite is the default and works for testing, but it is a single file that handles concurrent writes poorly and is easy to lose when a container restarts. PostgreSQL supports multiple processes, proper automated backups, and point-in-time recovery, which is why n8n recommends it for any production instance you rely on.

What happens if I lose my N8N_ENCRYPTION_KEY?

Every credential n8n stores is encrypted with that key. If you lose it and cannot recover the original value, all saved credentials in your database become permanently unreadable, and you will have to re-enter each API token, password, and OAuth connection by hand. Set the key yourself and back it up before your first run.

Do I need Redis to self-host n8n?

No, not for a standard setup. A single n8n instance with PostgreSQL runs fine without Redis. You only add Redis when you enable queue mode, where it acts as the job queue that lets separate worker processes run executions in parallel. Add it once execution volume outgrows one process.

What are the main n8n alternatives?

For most people the real alternative is a different hosting method, not a different tool: self-host on your own server, self-host on a PaaS, or pay for managed n8n Cloud. If you want a different product, options include hosted no-code automation services and other source-available workflow engines you can run yourself.

Can I run n8n without Docker?

Yes. You can install n8n through npm and run it with Node.js directly. Docker is recommended because it pins a known-good runtime, isolates dependencies, and makes upgrades a matter of pulling a new image tag. For self-hosting on a server or platform, the official Docker image is the path with the fewest surprises.

How do I keep n8n data in the EU?

Deploy the n8n container and its PostgreSQL database to an EU region. On Out Plane you can choose Nuremberg or Helsinki, which keeps your workflow definitions, execution history, and encrypted credentials physically in Europe. This is a data residency choice about server location, not a legal certification or a claim about jurisdiction.

Is self-hosted n8n secure enough for production?

It can be, and the defaults do most of the work: credentials are encrypted at rest with your encryption key, and HTTPS protects data in transit. Beyond that, protect the instance with authentication, keep the image on a current version, restrict network access to the database, and store your encryption key outside the container.

Conclusion

Running n8n self-hosted is free and entirely practical, as long as you move past the default. The three changes that separate a demo from a production instance are the same every time: back it with PostgreSQL instead of SQLite, set a fixed N8N_ENCRYPTION_KEY and save it, and use persistent storage so nothing evaporates on restart. Add Redis and queue mode only when execution volume demands it.

You can carry all of that yourself on a raw server, or hand the operating system, HTTPS, and database maintenance to a platform and keep control of the container. To take the second path, create an app from the official n8n image in the console at https://console.outplane.com, attach a managed PostgreSQL database, set your environment variables, and you have a working instance on a public HTTPS URL. The permanent free Hobby tier plus $20 in trial credit with no credit card is enough to stand one up today. See pricing for the details.