What Is n8n and How Do You Self-Host It with Docker?

What is n8n, and how do you self-host n8n?

n8n is a workflow automation tool that connects apps and services through visual nodes. To self-host n8n, you prepare a Linux server with Docker, start the container with a persistent volume, put it behind a domain with HTTPS, and back up the database together with the encryption key. n8n Cloud handles all of this for you.

In this guide we explain what n8n does, what its license allows, and how a Docker setup works in practice. We took the commands, the image name and the environment variables from the official n8n documentation. We also ask one honest question in every section: should you run this yourself, or hand it to a managed service? Installing takes an afternoon. Operating it takes ongoing attention.

What can you automate with n8n?

n8n works best for repetitive tasks that follow clear rules. For example, when someone submits the contact form on your website, n8n can add a row to a spreadsheet, email your sales team and create a new lead in your CRM. You build that as a single workflow with little or no code.

Typical use cases look like this:

• Collecting leads from forms, ad platforms and chat channels in one list.
• Sending e-commerce orders to accounting or shipping software.
• Emailing a daily or weekly report to the right person every morning.
• Pulling data from an API and writing it to Google Sheets or a database.
• Asking a language model to summarize text and posting the result to a channel.

That said, n8n is not the answer to everything. High volume pipelines that need millisecond precision often call for custom software instead. If you are still comparing approaches, our guide to AI in web design and automation gives broader context on where automation pays off.

What do trigger, node and workflow mean in n8n?

Put simply, every automation in n8n is a workflow. A workflow consists of nodes that you connect from left to right. The first node is usually a trigger, in other words the event that starts the run. The nodes after it process the data, transform it or send it to another service.

You can think of triggers in three groups. A schedule trigger starts the workflow at fixed intervals. A webhook trigger waits for an incoming HTTP request. App triggers listen for events in a connected service. So if you plan to use webhooks, your n8n instance needs an address that the public internet can reach.

In practice, data moves between nodes as JSON objects. Credentials live in a separate store, and nodes only reference them. As a result, you never paste an API key into each node by hand. In short, workflow logic and secrets stay apart, and that separation matters again when we reach backups and security.

What do the AI nodes in n8n actually do?

The official n8n node catalog includes an AI Agent node, plus sub-nodes for the model, memory and tools that plug into it. With this setup you can place a language model in the middle of a workflow. For instance, you can classify an incoming email, route it to the right team and draft a short reply.

Keep one point in mind: the AI node does not run a model on its own. You connect either an API key from a cloud model provider or a local model server on your own machine. Therefore you make the cost, privacy and speed decisions on the model side, not inside n8n.

Agent architecture, tool permissions and prompt injection risks deserve their own article. We covered them in our self-hosted AI agent guide, so we will not repeat them here. This article focuses on giving n8n itself a solid foundation, because an agent is only as reliable as the platform underneath it.

What does the n8n license allow for commercial use?

n8n is source available, but it does not meet the OSI definition of open source. According to the official license page, the main code uses the Sustainable Use License, while files with ".ee." in their name fall under the n8n Enterprise License. n8n calls this model "fair-code".

The license gives you the right to use, modify and redistribute the software for free, with three limits. First, you may use it only for your own internal business purposes, or for non-commercial and personal use. Second, you may distribute it only free of charge and for non-commercial purposes. Third, you may not remove licensing or copyright notices.

The n8n license FAQ offers practical examples. Building automations for a client on your own instance and charging consulting fees is fine, as long as the client cannot create or edit workflows. On the other hand, hosting n8n as a service where clients build their own workflows, or white-labeling it, falls outside the license.

If your case sits in a gray area, n8n asks you to email license@n8n.io. This section is general information, not legal advice. If you plan a commercial product, read the official n8n license FAQ and talk to a lawyer where needed.

n8n Cloud or self-hosted: which one fits you?

n8n offers two main options: the managed cloud version and an installation that runs on your own infrastructure. The official decision page recommends the cloud for people without technical expertise or without interest in managing servers. It points users who want full control and have infrastructure skills toward self-hosting.

Read the table with one caveat in mind. Self-hosting may look free, but server rent, your time and the operational risk all land on your side. If you have not picked a server type yet, our comparison of VPS, cloud server and VDS options makes that choice easier.

What do you need before you self-host n8n?

The official n8n Docker documentation recommends self-hosting for experienced users. It lists server and container setup, resource management, security and n8n configuration as required knowledge. It also states plainly that mistakes can lead to data loss, security issues and downtime.

Before you start, work through this list:

1. A current Linux server with SSH key login.
2. Docker Engine and the Docker Compose plugin, installed with the steps on the official Docker site.
3. A dedicated subdomain such as n8n.example.com, with an A record that points to your server IP.
4. Firewall rules that only open ports 22, 80 and 443.
5. A password manager entry for the encryption key and the database password.

If you are starting from a blank machine, begin with our guide to Ubuntu Server initial setup. If Docker is new to you, our Docker containers guide explains images, containers and volumes. You can confirm that your DNS record has propagated with our DNS lookup tool.

How do you try n8n with a single Docker command?

For a quick test, the two commands from the official n8n documentation are enough. The first creates a persistent Docker volume. The second starts the container and mounts that volume. Replace the timezone with your own IANA name, for example America/New_York or Europe/London.

docker volume create n8n_data

docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE="Europe/London" \
 -e TZ="Europe/London" \
 -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
 -v n8n_data:/home/node/.n8n \
 n8nio/n8n

This publishes port 5678 and mounts your data at /home/node/.n8n inside the container. GENERIC_TIMEZONE controls the time for schedule nodes, while TZ sets the system clock. Then open localhost:5678 in your browser and create the owner account.

However, this command does not suit a permanent setup. The container stops when you close the terminal, there is no HTTPS, and the port stays open to the outside. Use it on a local machine or a throwaway test server. For anything lasting, move on to the Compose setup in the next section.

How do you structure Docker Compose to self-host n8n in production?

For production, we recommend running n8n with PostgreSQL through Docker Compose. The skeleton below combines settings from the official n8n Docker Compose guide and its PostgreSQL examples. The values are placeholders. Replace the image tags with the current stable release that n8n supports.

services:
  postgres:
    image: postgres:SUPPORTED_VERSION
    restart: always
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGDATA: /var/lib/postgresql/data
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

This first part defines the PostgreSQL service. Thanks to the health check, n8n will not start before the database is ready. Next, append the n8n service and the two persistent volumes to the same file:

  n8n:
    image: n8nio/n8n:STABLE_VERSION
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: "5432"
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://n8n.example.com/
      N8N_PROXY_HOPS: "1"
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      GENERIC_TIMEZONE: Europe/London
      TZ: Europe/London
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  db_data:
  n8n_data:

Notice that we bound the n8n port to 127.0.0.1 only. That way nobody reaches n8n directly; traffic arrives through the reverse proxy. Also keep the PGDATA line. The n8n docs note that newer PostgreSQL releases changed the default data path, and without this line your volume may stay empty.

Which environment variables matter most?

In practice, you configure most of n8n through environment variables. Instead of writing secrets into the Compose file, put them in a .env file in the same folder. Keep that file out of version control; the n8n documentation gives the same advice.

POSTGRES_USER=n8n_user
POSTGRES_PASSWORD=REPLACE_WITH_A_STRONG_PASSWORD
POSTGRES_DB=n8n
N8N_ENCRYPTION_KEY=REPLACE_WITH_A_LONG_RANDOM_VALUE

To generate a random key, you can use a standard command such as openssl rand -hex 32. The table below covers the variables that people mix up most often:

Watch out for one change around the webhook address. The current n8n docs mark the old WEBHOOK_URL variable as deprecated; N8N_WEBHOOK_URL replaces it. If you still use the old name, n8n logs a deprecation warning. Check this difference whenever you copy an older tutorial.

Should you choose SQLite or PostgreSQL?

When you self-host n8n, it uses SQLite by default. Credentials, workflows and past executions live in the database.sqlite file inside the ~/.n8n folder. In a Docker setup, that folder maps to the n8n_data volume.

The n8n Compose guide says SQLite is fine for trying things out. However, it recommends PostgreSQL for production instances that serve more than a handful of users or run workflows around the clock. The docs also list the supported PostgreSQL major versions and note that this range shifts every year. So check the current n8n database page rather than a number you saw in another tutorial.

One more point deserves attention: moving from SQLite to PostgreSQL does not happen on its own. According to the official docs, the PostgreSQL setup is for a fresh instance, and n8n does not migrate existing SQLite data automatically. Therefore make the database decision on day one. For container details, see our guide to PostgreSQL and MySQL in Docker.

Why do you need a domain, a reverse proxy and HTTPS?

Every workflow that uses webhooks needs external services to reach n8n. For that reason, you must give n8n a domain name and a valid TLS certificate. Also, the login screen and your credentials should never travel over plain HTTP.

The n8n reverse proxy documentation asks for three things. You define the webhook address by hand with N8N_WEBHOOK_URL. You set N8N_PROXY_HOPS to 1. The last proxy then forwards the X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto headers. Here is a simple Nginx example:

server {
    listen 443 ssl;
    server_name n8n.example.com;
    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

After that, add the certificate lines that match your own setup. If you prefer a tool with a web interface, our Nginx reverse proxy and Nginx Proxy Manager guide walks through it step by step. For the basics of certificates, see our SSL certificate guide.

How does your first workflow move data from a form webhook to email?

The best way to verify your installation is to build a simple but real workflow. Our sample scenario works like this. The contact form on your website sends a request to n8n on submit. n8n cleans the data, emails your sales team and adds the record to your CRM.

1. Create a new workflow and add a Webhook node as the trigger.
2. Choose POST as the HTTP method and set Header auth as the authentication method.
3. Use the test URL and send a sample submission from the form; the data appears in the editor.
4. Add an Edit Fields node to pick out the name, email and message fields.
5. Send the notification with an email node, then create the record with a CRM node.
6. Once you publish the workflow, put the production URL into your form.

According to the n8n Webhook documentation, the test and production URLs differ. Specifically, the test URL only works while the editor listens for a test event, and it shows the data in the editor. The production URL works once the workflow is live; you follow those runs in the Executions tab. In other words, if your form keeps the test URL, real submissions go nowhere.

How do you protect credentials and the encryption key?

n8n encrypts credentials before it writes them to the database. According to the official docs, n8n creates a random key on first launch and saves it in the config file inside ~/.n8n. If you define N8N_ENCRYPTION_KEY beforehand, n8n uses your key instead of generating its own.

Here is why this key matters so much. Even with a full database backup, you cannot decrypt your credentials without it. Consequently, you would need to re-enter every API key, OAuth connection and password. Store the key in at least two separate places, for example in a password manager and in an encrypted backup.

Also apply least privilege when you create credentials. Use a separate API key for each integration and turn off scopes you do not need. That way a leaked workflow only affects one service. The n8n docs also include a page on rotating encryption keys, and we suggest you put that on a maintenance calendar.

How do you back up and restore a self-hosted n8n instance?

The n8n backup documentation describes a complete backup in two parts. First comes the .n8n folder, which holds the config file and, with SQLite, the database itself. Second comes your external database if you use PostgreSQL. Because the database holds encrypted credentials, the .n8n folder always belongs in the backup.

You can also export workflows and credentials as JSON:

docker compose exec n8n n8n export:workflow --backup --output=/home/node/.n8n/backup/workflows/
docker compose exec n8n n8n export:credentials --backup --output=/home/node/.n8n/backup/credentials/

However, the docs point out that this export leaves out users, execution history, variables and the encryption key. A CLI backup is enough to move workflows, but not to recover a whole instance. If you use SQLite, stop n8n before you copy the folder; otherwise you risk an inconsistent copy.

For the database side, follow our guide to backup and restore with pg_dump. Never leave backups on the same server. For the bigger picture, read our website backup strategy guide.

How do you update n8n safely once you self-host n8n?

The n8n docs say a new minor version ships most weeks, and they recommend the stable channel for production. That pace means you need an update routine. Still, you do not have to install every release on day one.

We suggest this order:

1. Read the release notes, especially changes to environment variables and behavior.
2. Take a full backup: the .n8n folder, a database dump and the .env file.
3. Change the image tag in your Compose file to the new stable release.
4. Run docker compose pull, then docker compose up -d.
5. Follow the logs with docker compose logs -f n8n and test critical workflows by hand.

Above all, pinning the tag is a valuable habit. An untagged image jumps to the latest stable release on every pull, which can change behavior when you least expect it. On the other hand, postponing updates for months means missing security fixes. So keep the schedule fixed and choose each version on purpose.

Which settings secure the editor and your webhooks?

The n8n editor is a control room that holds the keys to all your integrations. Therefore treat it like an admin panel, not like an ordinary web app. Give the owner account you create on first launch a strong password and turn on two-factor authentication.

• Restrict access to the editor with a VPN or an IP allowlist where you can.
• Use Basic auth, Header auth or JWT auth on Webhook nodes; the docs also offer an IP allowlist option.
• Block nodes you do not use through an environment variable, and disable the public API if you do not need it.
• Run the built-in security audit with the n8n audit command on a regular basis.
• Remember that Docker can bypass host firewall rules for published ports, so bind the port to 127.0.0.1.

The official audit report lists unused credentials, risky expressions in SQL nodes and nodes that touch the file system. Running it after each update is also a good habit. For a wider view of web application risks, see our OWASP Top 10 guide.

How many resources does n8n use, and how do you size the server?

Resource usage depends far more on the workload than on how you self-host n8n. An instance that runs a few scheduled workflows a day needs a very different server than one that answers thousands of webhooks per minute. That is why we do not give you a fixed number. Measure first, then decide.

The only concrete threshold in the docs relates to the sandbox stack that runs AI generated code for n8n Assistant. The n8n Compose guide asks for at least 4 GB of RAM and 2 vCPUs for that stack, because it runs Docker inside Docker. Without that stack, your needs will differ.

When sizing, watch memory usage, long running executions and large binary files. For instance, workflows that process PDFs or images fill memory quickly. For webhook traffic, keep the documented 16 MB default payload limit in mind; you can change it with N8N_PAYLOAD_SIZE_MAX. If load really grows, move on to the n8n queue mode documentation.

What mistakes do people make when they self-host n8n?

When we read the official docs and community questions, the same mistakes come up again and again. Most are small technically, yet their consequences are large. Before you go live, check this list once:

• Starting the container without a persistent volume, so all workflows vanish with the container.
• Skipping the encryption key backup and losing credentials during a server move.
• Exposing port 5678 directly and using the editor without HTTPS.
• Forgetting N8N_WEBHOOK_URL behind a reverse proxy.
• Running an untagged image and picking up updates without noticing.
• Starting on SQLite and later moving data by hand after the instance grows.

What these mistakes share is that none of them causes trouble on day one. The problem only shows up during a migration, an update or a security incident. Put simply, a solid decision to self-host n8n shows in how well you prepare for those moments, not in the first successful run.

When should you not self-host n8n?

To be honest, running your own n8n server is not the right call for every business. If nobody on your team will follow Linux updates, test backups and react to security alerts, a managed option is safer. The real cost of an installation shows up in the months after launch, not on day one.

We recommend leaving the job to n8n Cloud, or to a provider that manages the server for you, in these cases:

• Nobody on your team feels comfortable with SSH and Docker.
• A workflow outage directly costs you sales or payments.
• You lack the time to take backups and rehearse restores.
• You use shared hosting; these environments usually do not allow Docker.

On the other hand, if data location, custom integrations or cost give you solid reasons, running it yourself can make sense. If you want help with workflow design and integrations, take a look at our AI automation services page. Whatever you choose, decide early who owns the server.

Checklist for the first week after setup

When the installation finishes, you are only halfway there. The other half is confirming that the system behaves as expected for a full week. Tick off the list below during that first week.

• The HTTPS address responds, and HTTP requests redirect to HTTPS.
• Nobody can reach port 5678 through the public server IP.
• The owner account has two-factor authentication turned on.
• You keep N8N_ENCRYPTION_KEY in a safe place outside the server.
• Database and .n8n folder backups go to another location, and you have rehearsed a restore at least once.
• Webhook nodes require authentication, and your forms use the production URL.
• The n8n audit report comes back clean, or you have logged the findings.

Once you self-host n8n and pass this list, you can add new workflows with confidence. If AI nodes come next, plan agent permissions and human approval steps from the start. That way automation saves you time while you stay in control.