n8n Install: Four Methods, and What Each One Commits You To

There are four realistic ways to install n8n: the one-line setup script, Docker, Docker Compose with Postgres, and npm. All four get you a running editor in under ten minutes. The difference is not installation difficulty, it is what each one commits you to operationally six months later.

The n8n docs are honest about this in a quiet way. They list npm as an option and then add a line suggesting you consider Docker Compose instead. That parenthetical is the whole article. Installing n8n is easy. Running it as something your business depends on is a database decision, a TLS decision, and an upgrade decision that you make once and live with.

Table of contents

• The four install methods, ranked by what they cost you later
• The npm install, and why it is a trap for anything real
• Docker: the single-container version and its one real flaw
• Docker Compose with Postgres: the version worth typing
• TLS, and the part nobody puts in the install guide
• Upgrades, backups, and the two things that actually go wrong
• When the managed version is the right answer
• How this fits the rest of the stack
• FAQ

The four install methods, ranked by what they cost you later

Every guide covers the commands. Almost none covers the consequence. Here is the honest ranking, from least to most operational debt.

1. Docker Compose with Postgres. More YAML up front, least regret later. The workflow data lives in a real database, upgrades are an image tag change, and the container is disposable.
2. Docker, single container. Fine for evaluation. Defaults to SQLite in a volume, which works until concurrency or a corrupted file says otherwise.
3. The one-line setup script. Fastest path to a working editor on a fresh Linux or macOS box. It wires dependencies for you, which is convenient right up to the moment you need to know what it wired.
4. npm global install. Runs n8n directly on the host with whatever Node version happens to be there. Easiest to break, hardest to reproduce.

Notice that the ranking is inverted from the order most tutorials present them in. Tutorials lead with npm because it is one command. That is a demo, not a deployment.

The npm install, and why it is a trap for anything real

The command is exactly what you expect:

npm install n8n -g
n8n start

Open the printed URL and you have an editor. It works. The problem is everything the command did not tell you.

n8n is pinned to the Node version on that machine. Upgrade Node for an unrelated project and n8n may stop starting. There is no process supervisor, so a crash is a permanent outage until someone notices. There is no reverse proxy, so the editor is on a raw port with no TLS. And the data lives in a SQLite file under your home directory, which is not in any backup you have thought about.

Use npm to try n8n on a laptop for an afternoon. Do not use it for a workflow that sends invoices.

Docker: the single-container version and its one real flaw

The single-container run is the version most people actually start with.

docker volume create n8n_data

docker run -d --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e GENERIC_TIMEZONE=Europe/Lisbon \
  -e TZ=Europe/Lisbon \
  docker.n8n.io/n8nio/n8n

The named volume is the important part. Without it, docker rm deletes every workflow and every credential you have created, and there is no undo. People discover this while cleaning up containers, which is the worst possible moment.

The flaw is the default database. n8n stores everything in SQLite inside that volume. For one person and a handful of workflows this is genuinely fine. It stops being fine when executions start overlapping, because SQLite serialises writes, and a busy execution log is a lot of writes. The symptom is not a clean error. It is workflows that get slower and occasionally time out for reasons the logs do not explain.

Docker Compose with Postgres: the version worth typing

This is the install that survives contact with production. Two services, one network, workflow state in Postgres instead of a file.

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: [CMD-SHELL, pg_isready -U n8n]
      interval: 10s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - 5678:5678
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_ENCRYPTION_KEY: generate-a-long-random-string
      WEBHOOK_URL: https://automation.example.com/
      N8N_HOST: automation.example.com
      N8N_PROTOCOL: https
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  pg_data:
  n8n_data:

Three of those environment variables deserve a sentence each, because they are the ones people leave out and then debug for a day.

• N8N_ENCRYPTION_KEY encrypts stored credentials. If you do not set it, n8n generates one and writes it into the volume. Lose the volume and every saved credential becomes unreadable ciphertext, even though the workflows survived in Postgres.
• WEBHOOK_URL is the public address n8n hands to external services. Behind a reverse proxy, n8n cannot guess this. Get it wrong and every webhook trigger registers a URL nobody can reach.
• DB_TYPE: postgresdb is the entire point. Set it on day one. Migrating from SQLite to Postgres later is possible and nobody enjoys it.

TLS, and the part nobody puts in the install guide

n8n does not terminate TLS. It expects something in front of it. That something is a reverse proxy, and it is a permanent piece of infrastructure you now own.

The minimum viable setup is nginx or Caddy on the same host, a certificate from Let’s Encrypt, and a renewal timer. Caddy is the shorter path because it does certificate issuance and renewal without being asked:

automation.example.com {
    reverse_proxy n8n:5678
}

Two lines, and it handles the certificate. The catch is that you are still responsible for the host it runs on: the security updates, the disk filling with execution logs, the renewal that fails silently because a firewall rule changed in month seven.

This is the honest total cost of a self-hosted n8n install. Not the docker command. The proxy, the certificate lifecycle, the Postgres backups, and the upgrade you keep postponing because the last one broke a node.

Upgrades, backups, and the two things that actually go wrong

Upgrading a Compose install is a tag change and a restart:

docker compose pull
docker compose up -d

That is genuinely easy, which is why people do it without reading the release notes. n8n moves quickly, and node behaviour occasionally changes between minor versions. Pin an explicit version tag rather than tracking latest, read the notes, and upgrade deliberately.

For backups, two things matter and they are not the same thing. The Postgres database holds your workflows and execution history. The n8n data volume holds the encryption key. A backup of one without the other restores to a system that knows about your workflows but cannot decrypt any credential they use. Back up both, and test the restore once, before you need it.

The two failures that actually happen in practice: a disk that filled with execution data because nobody set a pruning policy, and a credential store that could not be decrypted after a host rebuild. Both are boring. Both take a site down.

When the managed version is the right answer

Self-hosting n8n is worth it when you need workflows inside a private network, when data cannot leave your infrastructure, or when you genuinely enjoy this class of work. Those are real reasons and this guide is here to make that path work.

If none of them apply, the calculation is simpler than it looks. A small VPS, a reverse proxy, a Postgres instance, certificate renewal, and the hours spent on upgrades add up to more than the automation is saving. On RunxBuild, n8n is a managed tool: it deploys on a $6 Basic plan with a custom domain, environment variables, autoscaling, and runtime logs, with a managed Postgres beside it on the same ladder. The certificate, the proxy, and the database backups stop being your problem.

Pick the option that matches how much infrastructure you want to own. Both are defensible. Only one of them requires you to remember what a renewal timer is.

How this fits the rest of the stack

An n8n install is a five-minute task attached to a multi-year commitment. Before you pick the method, price the whole thing: the runtime, the database beside it, the storage the execution log will grow into, and the bandwidth the webhooks will pull. The RunxBuild hosting calculator puts those line items on one page, which is a better way to make the build-versus-managed decision than discovering the answer six months in.

Useful related references:

• n8n vs Make: Where the Complexity Goes
• n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
• n8n Alternatives: The Honest Comparison by What You Are Escaping
• Services on RunxBuild

FAQ

Should I install n8n with npm or Docker?

Docker, in almost every case. The npm install ties n8n to the host Node version, has no process supervision, and stores data in a home directory nobody backs up. Docker Compose with Postgres is the version that survives a host rebuild.

Does n8n need a database?

It needs one either way. By default it uses SQLite inside its data volume, which is fine for a single user and a few workflows. Set DB_TYPE to postgresdb from the start if the instance will run anything real, because migrating later is unpleasant.

What is N8N_ENCRYPTION_KEY and do I have to set it?

It encrypts stored credentials. If you leave it unset, n8n generates one and writes it into the data volume. Lose that volume and every saved credential is unrecoverable even if your workflow database survived. Set it explicitly and store it with your other secrets.

Why do my webhooks return the wrong URL?

n8n cannot detect its public address from behind a reverse proxy. Set WEBHOOK_URL, N8N_HOST, and N8N_PROTOCOL to match the public hostname, then restart. Until you do, n8n registers webhook URLs pointing at its internal port.

How much does self-hosting n8n actually cost?

The server is the small part. Add a reverse proxy with certificate renewal, a Postgres instance, backups for both the database and the encryption key, and the time spent on version upgrades. Price all of it before comparing against a managed deployment.