n8n Self-Hosting Guide: Own Your Automation on EU Infrastructure

What Self-Hosting n8n Means

Self-hosting n8n means running the n8n workflow automation engine on a server you control, instead of paying for n8n Cloud or a per-task SaaS like Zapier. You install n8n on a virtual private server (VPS), point it at your own database, and every workflow execution happens on hardware you own. Your customer data, API keys, and webhook payloads never leave your infrastructure.

n8n is a node-based automation tool: you connect triggers (a webhook, a schedule, a new CRM record) to actions (send an email, write to a database, call an API, run an AI model) by wiring nodes together on a visual canvas. The difference from Zapier or Make is not the canvas. It is where the engine runs and how you pay for it.

This guide covers why companies self-host n8n, the licensing reality (it is not what most people assume), a Docker-based setup outline, how to secure it properly, how to scale it with queue mode, and the honest tradeoff between doing it yourself and having it managed.

If you want the implementation done for you on German servers, see our n8n automation service. If you are deciding between custom automation infrastructure and SaaS more broadly, see our automation service.

Why Self-Host n8n at All

There are three concrete reasons, and they compound.

Reason 1: No Per-Execution Fees

This is the cost argument, and it is the sharpest one. n8n counts one entire workflow run as a single execution, no matter how many nodes it contains. Zapier charges per task, where every individual step is one task.

Work through the math on a realistic workflow:

Workflow: 10 nodes (trigger + 9 actions)
Volume:   10,000 runs per month

n8n  (self-hosted): 10,000 executions  -> server cost only
Zapier (per task):  10 steps x 10,000  = 100,000 tasks billed

That is roughly a 90% difference in billable units for identical work. On Zapier or Make, cost scales with how much you automate, which quietly punishes success. On self-hosted n8n, cost is the server, and the server does not care whether you run 1,000 or 1,000,000 executions until you genuinely outgrow the hardware.

For comparison, n8n Cloud pricing starts at 20 EUR per month for 2,500 executions, 50 EUR for 10,000, and 667 EUR for 40,000. Self-hosted Community Edition is free software; you pay only for the VPS, which is typically in the 5 to 20 EUR per month range for a small but capable instance.

When you self-host n8n on an EU or German server, the data flowing through your workflows stays on your infrastructure. There is no third-party SaaS processor sitting between your CRM and your database, which means no Auftragsverarbeitungsvertrag (data processing agreement) with a US cloud vendor, and no question about transatlantic data transfers.

This matters most when workflows touch personal data: lead records, support tickets, invoices, anything with a name and an email. Keeping that processing inside your own perimeter is a materially simpler compliance story than routing it through a US-headquartered automation cloud. This is fachliche Einordnung, not legal advice, but it removes an entire category of data-transfer questions from the table.

For teams whose whole reason for being on EU infrastructure is compliance, this is often the decisive factor before cost even enters the conversation.

Reason 3: No Vendor Lock-In

Your workflows are JSON. Your engine is software you can move between servers. Your database is standard PostgreSQL. If you outgrow one VPS, you move to a bigger one or to a cluster. Nothing about your automation logic is trapped inside a proprietary platform you cannot export from.

The Licensing Reality: n8n Is Fair-Code, Not Open Source

This is the single most misunderstood thing about n8n, and getting it wrong leads to bad decisions.

n8n is not open source in the OSI sense. It is fair-code, published under the Sustainable Use License. The source is available on GitHub, and the Community Edition is free to run, but the license carries restrictions that a true open-source license would not.

What the Sustainable Use License allows:

Running n8n for internal business purposes at no cost
Running it for personal and non-commercial use
Modifying the source for your own use

What it restricts:

You may not resell n8n as a hosted product to third parties
You may not offer it as a white-labeled SaaS to your own customers
Commercial redistribution as a product is gated behind n8n’s enterprise terms

For the overwhelming majority of companies, this distinction is irrelevant in practice: if you are running n8n to automate your own operations, you are squarely inside what the license permits, for free. The restriction only bites if your business model is to resell n8n itself.

The practical takeaway: do not describe n8n as “open source” in contracts, RFPs, or compliance documents. Describe it accurately as “fair-code, source-available, under the Sustainable Use License.” It avoids a credibility problem and it is simply correct.

Docker Setup Outline

Docker is the cleanest way to run n8n. It isolates the runtime, makes upgrades a one-line operation, and keeps your host server tidy. The reference setup is n8n plus a PostgreSQL database, behind a reverse proxy that handles HTTPS.

Do not run a production n8n on the default SQLite database. SQLite is fine for a five-minute test and a liability for anything real. Use PostgreSQL from day one.

Here is a minimal docker-compose.yml skeleton that captures the right shape:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change-me-strong
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me-strong
      - N8N_HOST=automation.yourcompany.de
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://automation.yourcompany.de/
      - N8N_ENCRYPTION_KEY=generate-a-long-random-secret
      - GENERIC_TIMEZONE=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres

volumes:
  postgres_data:
  n8n_data:

Two values in there are not optional:

N8N_ENCRYPTION_KEY encrypts your stored credentials. If you lose it, every saved credential becomes unreadable. Generate it once with openssl rand -hex 32, store it in your password manager, and never rotate it casually.
WEBHOOK_URL must be the public HTTPS address external services will call back to. If this is wrong, inbound webhooks silently fail.

Note that the n8n port is bound to 127.0.0.1, not 0.0.0.0. The engine should never face the public internet directly. A reverse proxy in front of it terminates TLS and is the only thing exposed.

Securing Your n8n Instance

A self-hosted automation engine holds the keys to your entire stack: CRM credentials, payment-provider tokens, email API keys. Securing it is not optional polish. Treat it like production infrastructure, because it is.

HTTPS via a Reverse Proxy

Put Caddy, Traefik, or nginx in front of n8n and let it handle TLS. Caddy is the fastest to stand up because it provisions and renews Let’s Encrypt certificates automatically:

automation.yourcompany.de {
    reverse_proxy 127.0.0.1:5678
}

That is the entire Caddy config for a working HTTPS frontend. n8n itself stays on localhost; the proxy is the only public surface.

Authentication

n8n’s user management (email plus password, with role-based access) is the baseline. Strengthen it:

Use strong, unique credentials and enable two-factor authentication
Restrict the admin UI to known IP ranges at the firewall or proxy layer where feasible
For teams, give people their own accounts rather than sharing one login, so you have an audit trail
Keep the instance off the public internet entirely if it only serves internal automations, reachable via VPN

Backups

You have two things to back up, and you need both:

The PostgreSQL database holds your workflows, execution history, and encrypted credentials. Back it up with scheduled pg_dump runs (a nightly cron is the minimum).
The N8N_ENCRYPTION_KEY is what makes those credentials readable. A database backup without the key is a backup of encrypted garbage.

# Nightly database dump
pg_dump -U n8n n8n | gzip > /backups/n8n-$(date +%F).sql.gz

Store backups off the host, ideally on separate EU storage, and test a restore at least once. An untested backup is a hope, not a backup.

Keep It Updated

n8n ships frequently. With Docker, an upgrade is pulling the new image and recreating the container. Read the release notes before major version jumps, take a database backup first, and you will rarely have a bad day.

Scaling n8n with Queue Mode

A default n8n runs in a single process. That is fine until you hit volume, long-running jobs, or many concurrent webhooks. When you do, the answer is queue mode.

In queue mode, n8n separates the role that receives triggers (the main instance) from the roles that actually run workflows (worker instances), coordinated through a Redis queue:

                +----------------+
   webhooks --> |  main instance | --> Redis queue
                +----------------+          |
                                            v
                              +-------------------------+
                              |  worker 1   worker 2 ...|  (horizontally scalable)
                              +-------------------------+
                                            |
                                            v
                                   PostgreSQL (shared)

The main instance stays responsive because it is not blocked running heavy workflows. Workers pull jobs off the queue and execute them in parallel. Need more throughput? Add more workers. This is how a self-hosted instance handles serious production load without touching the per-execution wall that a SaaS tool would.

You do not need queue mode on day one. Start single-process, and move to queue mode when execution backlog or webhook latency tells you it is time. The migration is configuration, not a rewrite.

Use Cases: What Companies Actually Automate

Self-hosted n8n earns its place on common, high-frequency business workflows:

Lead capture and routing: a form submission or inbound webhook creates a CRM record, assigns an owner, and posts a notification, in seconds and without manual triage.
Lead enrichment and scoring: incoming leads get enriched from external data sources and scored, so sales spends time on the right contacts.
CRM data hygiene: scheduled workflows deduplicate records, normalize fields, and flag stale entries automatically.
Document and invoice workflows: generate, route, and file documents; push invoice data between billing and accounting systems.
Internal ops and IT: provisioning, alerting, syncing data between internal tools, and the long tail of glue work that otherwise eats engineering hours.

The documented enterprise ROI is real. Delivery Hero runs a single n8n workflow that saves its IT team over 200 hours per month. StepStone integrates new data sources roughly 25 times faster than before, turning work that took two weeks into a couple of hours. These are not toy automations; they are core operational workflows running on the same engine you can self-host.

AI Workflows on Your Own Server

This is where self-hosting becomes a genuine strategic advantage rather than just a cost play.

n8n ships 70+ AI-specific nodes built on LangChain. It supports AI agents, retrieval-augmented generation (RAG) pipelines, and the major vector databases (Pinecone, Qdrant, Weaviate, Chroma), plus more than a dozen LLM providers. Critically, it supports local models via Ollama.

That last point is the unlock. You can build a complete LLM pipeline, document ingestion, embedding, vector search, generation, that runs entirely on your own server, with the model itself running locally through Ollama. Your prompts and your documents never touch OpenAI or any external API. For companies handling sensitive or regulated data, this is sovereign AI: the intelligence layer lives inside the same EU perimeter as everything else.

A typical RAG-on-your-own-infrastructure shape looks like this:

documents --> [embed via local model] --> [vector DB: Qdrant]
user query --> [retrieve relevant chunks] --> [local LLM via Ollama] --> answer
                                  (all nodes running inside your n8n instance)

n8n even publishes a self-hosted AI starter kit that bundles n8n, Ollama, and a vector database together, so the components are designed to run side by side. If a chatbot, internal knowledge assistant, or document-processing agent is on your roadmap and the data is sensitive, this architecture lets you build it without exporting that data anywhere.

DIY vs Managed: The Honest Tradeoff

Self-hosting n8n is genuinely accessible. A basic Docker setup is a one-to-three-hour job for someone comfortable on a Linux server. So when does it make sense to manage it yourself, and when not?

DIY makes sense when:

You have in-house ops or DevOps capacity
The workflows are internal and not business-critical at first
You want to learn the platform deeply
Downtime on automation is an annoyance, not a revenue event

Managed makes sense when:

Automation is load-bearing and downtime costs real money
Nobody on the team wants to own server patching, backups, monitoring, and version upgrades
You need the GDPR and security posture to be demonstrably correct, not improvised
You would rather your people build workflows than babysit infrastructure

The hidden cost of DIY is not the initial setup; it is the ongoing operational tax. Updates, backup verification, monitoring, security patches, queue-mode tuning, and incident response add up. The engine is free. Running it well, indefinitely, is the actual work.

If you want n8n self-hosted on German infrastructure with the security, backups, monitoring, and updates handled, that is exactly what our n8n automation service delivers. And if your bigger question is whether to build custom automation infrastructure at all versus stitching together SaaS tools, our automation service walks through that decision.

Frequently Asked Questions

Is n8n free?

The self-hosted Community Edition is free software. You pay only for the server it runs on, typically 5 to 20 EUR per month for a small instance. n8n Cloud and Enterprise are paid, with cloud plans starting at 20 EUR per month for 2,500 executions.

Is n8n open source?

No. n8n is fair-code, source-available under the Sustainable Use License. You can run it free for internal business use, but you cannot resell it as a hosted product. Describe it as “fair-code,” not “open source,” to stay accurate.

Self-hosting on an EU or German server keeps your data inside your own infrastructure, which removes the data-transfer and processor questions that come with US SaaS automation. The setup itself does not make you compliant; how you secure and operate it does. This is fachliche Einordnung, not legal advice.

Do I need Docker to self-host n8n?

No, but it is strongly recommended. Docker makes installation, isolation, and upgrades dramatically simpler than a bare npm install, and it is the path n8n’s own documentation centers on.

When do I need queue mode?

When a single process can no longer keep up: execution backlogs, slow webhook responses, or many concurrent long-running workflows. Start single-process and move to queue mode (main instance plus workers plus Redis) when volume demands it.

Can I run AI workflows without sending data to OpenAI?

Yes. n8n supports local models via Ollama alongside its 70+ LangChain-based AI nodes and major vector databases. You can run a full RAG pipeline entirely on your own server, so prompts and documents never leave your infrastructure.

What happens if I lose the encryption key?

Every stored credential becomes unreadable. The N8N_ENCRYPTION_KEY is as important as the database itself. Generate it once, store it in a password manager, and include it in your disaster-recovery plan. A database backup without the key is useless.

Summary: Self-Hosting Checklist

Self-hosted n8n gives you automation without per-execution fees, on infrastructure you control, with a clean GDPR story and a real path to sovereign AI. The engine is free. The value is in running it well, deciding whether that is your team’s job or ours.

If automation is becoming load-bearing for your business, see our n8n automation service for a managed setup on German servers, or our automation service to weigh custom infrastructure against SaaS.