n8n self-hosted on a single-tenant server

What a self-hosted n8n consists of

• n8n, the n8nio/n8n image, listening on port 5678. Its data directory, /home/node/.n8n, holds the SQLite database and the encryption key.
• Traefik, in n8n's Compose guide, on ports 80 and 443. It gets certificates from Let's Encrypt through a TLS challenge and routes the subdomain to n8n. n8n's guide states the instance is only reachable over HTTPS.
• A DNS A record for the subdomain, pointing at the server's address, before the first start: the certificate request depends on it.
• Optionally, PostgreSQL and Redis. n8n uses SQLite out of the box. Postgres is configured with DB_TYPE=postgresdb, and Redis enters with queue mode.

Webhooks are why this is a server and not a laptop. A trigger from Stripe, GitHub or a form posts to a public HTTPS URL that n8n learns from N8N_WEBHOOK_URL (WEBHOOK_URL before n8n 2.30.0), and it has to answer at any hour.

Setting it up with Docker Compose

1. On a Linux server, install Docker Engine and the Compose plugin from Docker's instructions for your distribution, and check both answer.
2. Create the A record for the subdomain, for example n8n.example.com, pointing at the server.
3. Make a project directory with a local-files folder, the folder n8n reads and writes at /files.
4. Write the .env file below with your domain, subdomain, time zone and certificate email.
5. Paste compose.yaml from n8n's Docker Compose guide unchanged: Traefik on 80 and 443, n8n published on 127.0.0.1:5678 only, the n8n_data and traefik_data volumes.
6. Start it, then open the HTTPS address straight away.

docker --version
docker compose version
mkdir n8n-compose && cd n8n-compose
mkdir local-files

# .env
DOMAIN_NAME=example.com
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Europe/Berlin
SSL_EMAIL=user@example.com

# compose.yaml: copy it from n8n's Docker Compose guide, then
sudo docker compose up -d

The first person to open the address gets n8n's owner sign-up screen, and there is no supported way to turn the login screen off. Create the owner account the moment the instance answers, with a password of at least eight characters, a number and a capital letter.

The encryption key and backups

On first launch n8n generates a random encryption key and saves it in ~/.n8n, inside the n8n_data volume, and uses it to encrypt every credential before it reaches the database. A database restored without that key holds credentials nothing can read. Back up the volume as a whole, or set N8N_ENCRYPTION_KEY yourself and keep that value somewhere outside the server.

With the containers stopped, Docker's own volume-backup pattern copies the data directory to a tarball you then move off the machine:

sudo docker compose stop
sudo docker run --rm --volumes-from n8n-compose-n8n-1 -v "$(pwd)":/backup ubuntu tar cvf /backup/n8n-data.tar /home/node/.n8n
sudo docker compose up -d

SQLite, Postgres and queue mode

SQLite is fine for one person's automations. Execution history is what grows: n8n prunes it by default at 14 days or 10,000 executions, and on SQLite the space pruning frees is reused, not returned to the disk, until a VACUUM runs (DB_SQLITE_VACUUM_ON_STARTUP does it at start).

Queue mode is the next step when one process cannot keep up: a main instance takes triggers and webhooks, Redis queues the executions, and worker instances run them. Set EXECUTIONS_MODE=queue on the main instance and every worker, and give every worker the same N8N_ENCRYPTION_KEY. n8n's docs say a distributed setup over SQLite is not supported, so queue mode means moving the database first.

Workers can be more processes on the same machine or more machines. In New York, managed Kubernetes runs the control plane for you and keeps your own dedicated servers as the workers.

Why a whole server for it

n8n holds the keys to every system it automates: API tokens, database passwords, OAuth grants. On a single-tenant machine those sit on hardware nobody else's workload shares, with root yours and no virtualization layer underneath. The container servers are delivered in about 30 minutes once payment is verified.

Workflows that move files and API payloads all day are traffic, and the port is unmetered: nothing counts the bytes in either direction. The machines and the network are ours, on our own autonomous system, AS19624, in New York, Miami, San Francisco, Amsterdam and Bucharest, so the instance can sit next to the systems it calls.

Firewall and updates

• Docker publishes around ufw. Docker's documentation says the two are incompatible: packets to a published port are routed before ufw's rules apply. That is why n8n's guide publishes 5678 on 127.0.0.1 only. Keep it that way, and expect 80 and 443 to be open whatever ufw says.
• Update deliberately. n8n ships a new minor version most weeks. The Compose update is sudo docker compose pull, then down, then up -d from the project directory; to hold a version, replace image: n8nio/n8n in compose.yaml with the exact version tag you tested.
• Read access to files is fenced. The guide's N8N_RESTRICT_FILE_ACCESS_TO=/files limits file nodes to the local-files folder.

When self-hosting is the wrong call

n8n's own guide recommends self-hosting for expert users and points everyone else to n8n Cloud: servers, containers, scaling and security become your job, and mistakes cost data and uptime. If nobody on the team wants to own updates and backups, a hosted plan is the honest answer.

Check the licence too. n8n's Sustainable Use License permits use for your own internal business purposes or for non-commercial or personal use; providing n8n to others is allowed only free of charge for non-commercial purposes, and files marked .ee. need an enterprise licence.