n8n Self-Hosting With Docker: The Complete Setup Guide

People self-host n8n for three reasons that keep repeating. They want the data from their workflows to stay on infrastructure they control, they want to run as many executions as their server can handle, and they want the option to add custom nodes for internal systems that no public integration covers.

Docker is the path n8n documents first, and it is the one worth taking. It gives you a single artifact to move between your laptop and a server, it keeps the runtime out of your host's package manager, and it makes upgrades a pull instead of a migration. This guide follows the steps n8n publishes, then covers the parts their quickstart understandably skips.

What do you need before you start?

You need Docker and somewhere to run it. n8n's documentation lists Docker Desktop for Mac, Windows and Linux, or Docker Engine with Docker Compose installed separately on Linux. That is the entire prerequisite list for a first run.

For a local trial, your laptop is enough. For anything a colleague or an external service will call, you want a small always-on server and a domain name pointed at it, because a webhook that only exists on your laptop stops existing when you close the lid.

How do you run n8n with Docker?

You create a named Docker volume for the instance data, then start the official image with that volume mounted and port 5678 published. n8n documents both commands in full, so there is nothing to invent here.

Read that command once before you paste it. The two timezone variables do different jobs: n8n documents GENERIC_TIMEZONE as the timezone for schedule-oriented nodes, and TZ as the system timezone used by scripts and commands. If you set only one, a cron-style schedule and a shell command inside the same workflow can disagree about what nine in the morning means.

Your first run, start to finish

1. Install Docker — Docker Desktop on Mac or Windows, or Docker Engine plus Docker Compose on Linux. Confirm it works before you touch n8n.
2. Create the named volume — Run docker volume create n8n_data. This is where your instance data lives, separate from the container itself.
3. Start the container — Run the documented docker run command, replacing <YOUR_TIMEZONE> with your IANA timezone such as Europe/Amsterdam.
4. Open the editor — Go to http://localhost:5678 and set up the owner account n8n asks you to create on first launch.
5. Build one throwaway workflow — Before you configure anything else, confirm the instance actually executes something. A trigger and a single node is enough.

Where does your n8n data actually live?

In the volume, not the container. n8n's documentation is explicit that the command mounts the n8n_data volume to /home/node/.n8n so your data persists across container restarts. Delete the container and your workflows are still there. Delete the volume and they are gone.

That distinction is the whole reason the volume exists, and it is also the thing people forget on upgrade day. Practise the recovery before you need it: stop the container, remove it, start a fresh one against the same volume, and check that your workflows are still listed. Five minutes now saves a very bad afternoon later.

What is the encryption key and why set it first?

N8N_ENCRYPTION_KEY is the instance key that protects your stored credentials, and n8n's documentation says you set it at deployment time rather than expecting n8n to generate it for you. It is the master key in a two-layer scheme.

The second layer is handled for you. n8n's encryption key documentation states that on startup n8n automatically generates the initial data encryption key and stores it, encrypted, in your database. That data key is what encrypts credential data such as OAuth tokens. Your instance key is what protects the data keys.

n8n also documents a general convention that helps here: you can append _FILE to certain environment variables to supply their value from a separate file instead of the environment. That is the difference between a secret sitting in your shell history and a secret mounted from a file with sensible permissions.

Is there a faster way to install it?

Yes. n8n documents a one-line installer that pipes a script from get.n8n.io into your shell. It checks that Docker is installed and working, creates an n8n folder in your current directory, writes the configuration files, then downloads and starts the service.

Their page describes what you get by default: the editor at http://localhost:5678, SQLite as the built-in database for workflows and credentials, and a sandbox plus search backend for the optional AI Assistant. It is aimed at a fresh single-machine install rather than an existing Compose stack or a team setup on Postgres. Piping a remote script into a shell is a decision you should make deliberately, so read it first if that matters to you.

How do you run n8n with Docker Compose?

Compose is the same container described in a file instead of a command, which is what you want the moment more than one person depends on the instance. The snippet below is nothing more than the flags from n8n's documented docker run expressed in Compose form, plus a restart policy.

Start it with docker compose up -d and check it with docker compose ps. n8n's own Compose guidance is worth reading before you expose anything, and it is direct about network surface: port 5678 is the only port that should be internet-facing. Everything else in a larger stack talks over the internal Docker network.

How do you upgrade a self-hosted n8n?

You pull a newer image and restart against the same volume. For a plain Docker install, n8n documents docker pull docker.n8n.io/n8nio/n8n to fetch the latest stable version. For Compose installs the documented sequence is docker compose pull, then docker compose down, then docker compose up -d.

Set-up work like this is exactly what we removed at Sistava. Rather than provisioning a host, choosing an encryption strategy and owning an upgrade path before you have automated anything, you hire an AI Employee and tell it in plain English what you want handled. The tools are connected already, it asks you when it is unsure, and there is no instance to keep alive.

What does the free self-hosted edition include?

n8n describes the Community edition as offering almost the complete feature set, free and indefinitely. The gaps are the team and enterprise layers rather than the automation itself.

Their documentation lists what the Community edition does not include: Custom Variables, Environments, External secrets, External storage for binary data, Log streaming, Multi-main mode, Projects, SSO via SAML or LDAP, and sharing of workflows and credentials. If your plan involves several people owning workflows together, read that list carefully before you build.

There is also a registered tier that costs nothing. n8n documents that registering your instance with an email address adds three extra features at no cost: folders for organising workflows, Debug in editor for copying and pinning execution data, and Custom execution data for saving and annotating execution metadata. You request it from the three-dot menu under Settings, then Usage and plan, then Unlock.

What does the n8n licence allow you to do?

n8n publishes its terms as the Sustainable Use License, and their documentation states three limitations. You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute it or provide it to others only free of charge and for non-commercial purposes. And you may not alter, remove or obscure any licensing, copyright or other notices of the licensor in the software.

Their own reading of internal business purposes is broad. n8n's page says all use is allowed unless you are selling a product, service or module whose value derives entirely or substantially from n8n functionality, and it names consulting services and running n8n servers internally as permitted examples.

The cases their documentation flags as needing a separate commercial licence are the ones where n8n is the product: white-labelling n8n and offering it to your customers for money, hosting n8n and charging people to access it, and using it as a backend where your users supply their own credentials to reach their own data. If your plan is anywhere near that line, read their licence page yourself rather than a summary, including this one.

What do people get wrong on a self-hosted instance?

• Leaving the encryption key unset. n8n documents it as something you set at deployment time. Decide it before the first credential exists, not after.
• Putting the volume somewhere disposable. The container is meant to be thrown away. The volume is your entire instance.
• Only setting one timezone variable. GENERIC_TIMEZONE and TZ cover different things, and mismatches surface as schedules that fire at the wrong hour.
• Exposing more than port 5678. n8n's Compose guidance is explicit that 5678 is the only port that should be internet-facing.
• Treating an OAuth redirect as fixed. Google credentials need a redirect URL that matches how your instance is actually reached, which changes the day you move from localhost to a domain.

None of these are flaws in n8n. They are the standing cost of running your own automation service, and they are real whichever tool sits in the container. The honest question is whether that cost buys you something you need. If you want workflows on your own hardware with custom nodes talking to internal systems, it absolutely does.

If what you actually wanted was for the work to get done, that is a different question, and it is the one Sistava answers. An AI Employee has no instance to patch, no volume to back up and no upgrade window, because the thing you are hiring is the outcome rather than the infrastructure underneath it.

Sources

• n8n documentation, Install with Docker
• n8n documentation, Install using Docker Compose
• n8n documentation, One-line setup
• n8n documentation, Rotate encryption keys
• n8n documentation, Use environment variables
• n8n documentation, Community edition features
• n8n documentation, Sustainable Use License
• KDnuggets, How to Self-Host n8n on Docker in 5 Simple Steps