# n8n selbst hosten: Docker, Kosten & DSGVO 2026

> n8n selbst hosten mit Docker: komplettes Compose-Setup, echte Kosten (inkl. versteckter Wartung), DSGVO-Checkliste & wann Managed die bessere Wahl ist.

Veröffentlicht: 2026-07-10
Autor: Simon (alloq.digital)
HTML-Version: https://alloq.digital/de/blog/n8n-selbst-hosten/

---

**TL;DR:** n8n selbst hosten heißt: Du betreibst die kostenlose Community Edition per Docker Compose (n8n + Postgres + Reverse Proxy) auf einem eigenen VPS ab rund 5-6 € pro Monat. Rechnest du Wartung, Backups und Ausfallrisiko ehrlich ein, landen KMU bei realen Gesamtkosten von etwa 80-250 € pro Monat. Der DSGVO-Vorteil ist echt - aber nur mit EU-Serverstandort, AVV mit dem Hoster und einem sicher verwahrten Encryption-Key.

## n8n selbst hosten: Für wen sich das 2026 wirklich lohnt

![Kennzahlen-Karte zu den n8n Cloud Preisen im Vergleich beim Thema n8n selbst hosten](/blog/n8n-selbst-hosten-chart-1.svg)

*n8n Cloud rechnet nach Executions ab (jährliche Abrechnung); Self-Hosting kennt keine Execution-Limits.*

Wenn du n8n selbst hostest, läuft exakt dieselbe Software wie in der n8n Cloud - nur auf deiner eigenen Infrastruktur. Die [Community Edition steht als self-hosted Version frei auf GitHub bereit](https://n8n.io/pricing/), lizenziert nach dem Fair-Code-Modell. Du installierst sie, du betreibst sie, du haftest dafür.

Zwei Motive treiben praktisch jede Self-Hosting-Entscheidung:

1. **Datenkontrolle:** Bei selbst gehostetem n8n verlassen Workflow-Daten, API-Credentials und verarbeitete Informationen deine Infrastruktur nicht - für DSGVO-relevante Prozesse, Gesundheits- oder Finanzdaten ein handfestes Argument. Die n8n Cloud kann außerdem keine internen Datenbanken oder APIs hinter deiner Firewall erreichen.
2. **Kosten:** Die n8n Cloud rechnet nach Executions ab - [Starter kostet 20 €/Monat für 2.500 Workflow-Ausführungen, Pro 50 €/Monat für 10.000](https://n8n.io/pricing/) (jährlich abgerechnet). Die Community Edition kennt keine Execution-Limits; du zahlst nur den Server.

Für KMU mit 10-50 Mitarbeitern lautet die ehrliche Einordnung: Self-Hosting lohnt sich, wenn du viele Workflows betreibst, sensible Daten verarbeitest und jemand im Team Server administrieren kann und will. Self-Hosting ergibt keinen Sinn, wenn niemand Server, SSL und Updates verwalten möchte oder du gerade erst mit n8n startest. Als Bastelprojekt ohne Ops-Verantwortlichen wird es teurer als jede Cloud - dazu unten mehr.

Falls du noch bei den Grundlagen stehst: [n8n einfach erklärt - Kosten und Workflows im Überblick](/de/blog/n8n-einfach-erklaert/) liefert dir das Fundament vor der Hosting-Entscheidung.

## Voraussetzungen: Server, RAM und was du vorher brauchst

![Kennzahlen-Karte zur empfohlenen RAM-Ausstattung, wenn du n8n selbst hosten willst](/blog/n8n-selbst-hosten-chart-2.svg)

*Empfohlene Serverausstattung: mindestens 2 GB, für den produktiven Betrieb besser 4 GB RAM.*

Eine self-gehostete n8n-Infrastruktur besteht laut Cherry Servers aus vier Komponenten: einem Linux-Host, einer Laufzeitumgebung (Docker), einer Datenbank und einer öffentlich erreichbaren Adresse für Webhooks.

Konkret brauchst du:

- **VPS mit genug RAM:** Die empfohlene Serverausstattung für n8n liegt bei mindestens 2 GB RAM, besser 4 GB. Für den produktiven Betrieb mit Postgres nimm 4 GB RAM und 2 vCPU als Sweet Spot. Wichtig: Bei n8n zählt Arbeitsspeicher mehr als CPU-Leistung, weil die meiste Ausführungszeit auf HTTP-Antworten externer APIs wartet. Ein 4-GB-Server trägt typische KMU-Lasten mit einigen Dutzend Workflows problemlos; erst bei vielen parallelen Executions rüstest du auf oder wechselst in den Queue-Mode.
- **EU-Hoster:** Hetzner oder Hostinger bieten EU-Standorte - ein Serverstandort in Deutschland oder Europa ist für DSGVO-Konformität wichtig.
- **PostgreSQL statt SQLite:** n8n startet standardmäßig mit SQLite, aber [für persistente, produktive Daten gehört eine PostgreSQL-Datenbank ins Setup](https://northflank.com/blog/how-to-self-host-n8n-setup-architecture-and-pricing-guide) - sie übersteht Container-Neustarts sauber und lässt sich ordentlich sichern.
- **Domain + SSH-Zugang:** Eine Subdomain wie `n8n.deinefirma.de` und ein SSH-Key für den Server.
- **Reverse Proxy:** Für automatisches SSL - dazu gleich mehr.

## n8n mit Docker Compose einrichten: Schritt für Schritt

![Kennzahlen-Karte zur Setup-Zeit beim n8n selbst hosten mit Docker](/blog/n8n-selbst-hosten-chart-3.svg)

*ExpressTech beziffert die Setup-Zeit für Docker auf einem VPS auf 30 bis 60 Minuten.*

Docker Compose ist der De-facto-Standard für Self-Hosting: Ein einziges File beschreibt den kompletten Stack aus n8n, Postgres und Reverse Proxy - reproduzierbar, versionierbar, in Minuten neu aufsetzbar. ExpressTech beziffert die Setup-Zeit für Docker auf einem VPS mit 30-60 Minuten.

Erzeuge zuerst den Encryption-Key und lege ihn in eine `.env`-Datei:

```bash
openssl rand -hex 32
```

Dann das vollständige `docker-compose.yml` mit Caddy als Reverse Proxy:

```yaml
services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${DB_PASSWORD}   # aus .env, nicht ins Repo!
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      retries: 5

  n8n:
    # Version pinnen statt :latest - kontrollierte Updates!
    image: docker.n8n.io/n8nio/n8n:<version>
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${DB_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}  # verschlüsselt alle Credentials
      N8N_HOST: n8n.deinefirma.de
      WEBHOOK_URL: https://n8n.deinefirma.de/   # sonst zeigen Webhooks auf localhost
      N8N_PROTOCOL: https
      GENERIC_TIMEZONE: Europe/Berlin           # sonst laufen Cron-Trigger in UTC
    volumes:
      - n8n_data:/home/node/.n8n
    # Kein ports-Mapping: n8n bleibt intern, nur Caddy ist erreichbar

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data

volumes:
  postgres_data:
  n8n_data:
  caddy_data:
```

Das `Caddyfile` besteht aus drei Zeilen - Caddy holt und erneuert Let's-Encrypt-Zertifikate automatisch:

```
n8n.deinefirma.de {
    reverse_proxy n8n:5678
}
```

Port 5678 ist der [Standard-Port des offiziellen n8n-Images](https://northflank.com/blog/how-to-self-host-n8n-setup-architecture-and-pricing-guide). Mit `docker compose up -d` startet der Stack, danach legst du im Browser den Owner-Account an.

**Der wichtigste Satz dieses Artikels:** Der N8N_ENCRYPTION_KEY verschlüsselt deine gespeicherten Credentials - verlierst du ihn, verlierst du den Zugriff auf alle gespeicherten Zugangsdaten. Sichere ihn getrennt vom Server, etwa im Passwort-Manager des Unternehmens. Ein Backup ohne diesen Key ist für Credentials wertlos.

### Server härten und SSL: Firewall, Reverse Proxy, HTTPS

Bevor der Stack produktiv läuft, gehören vier Handgriffe dazu. Nach der Docker-Installation brauchst du laut ExpressTech zusätzlich Reverse Proxy, SSL-Zertifikat via Let's Encrypt, eine UFW-Firewall für die Ports 80, 443 und 22 sowie Backups per Cron-Job:

1. **Non-root-User anlegen** und SSH-Login für root deaktivieren.
2. **Firewall aktivieren:** `ufw allow 22,80,443/tcp && ufw enable` - alles andere bleibt zu.
3. **n8n nie direkt auf Port 5678 exponieren.** Im Compose-File oben fehlt das Port-Mapping für n8n bewusst: Nur der Reverse Proxy nimmt Verbindungen an.
4. **User-Management nutzen:** Lege den Owner-Account sofort nach dem ersten Start an und vergib für jedes Teammitglied einen eigenen Login mit starkem Passwort.

## Was n8n Self-Hosting wirklich kostet (TCO-Rechnung)

![Kennzahlen-Karte zu den realen Monatskosten, wenn KMU n8n selbst hosten](/blog/n8n-selbst-hosten-chart-4.svg)

*Reiner VPS-Preis vs. ehrliche Gesamtkosten inkl. Wartung, Backups und Monitoring für KMU.*

Jetzt zur unbequemen Wahrheit, die kaum ein Hosting-Guide ausspricht. Ja, ein eigener VPS für n8n kostet rund 5-6 € im Monat, und die Community Edition selbst ist kostenlose Software mit unbegrenzten Executions. Aber der Serverpreis ist nur die Spitze. Auch InstaPods listet ehrlich auf, was du zusätzlich brauchst: einen Server, Docker-Grundkenntnisse und Zeit für Wartung - Updates, Backups, SSL.

ExpressTech veranschlagt für Docker auf einem VPS etwa 1-2 Stunden Wartung pro Monat. Multipliziere das mit einem internen Stundensatz und die Rechnung kippt. Ein Rechenbeispiel für ein KMU (Stundensatz als Annahme mit 80-100 €, Wartungsaufwand konservativ mit 1-2 h/Monat angesetzt):

| Posten | Monatlich | Über 36 Monate |
|---|---|---|
| VPS 4 GB, EU-Standort | 6-13 € | 216-468 € |
| Backup-Storage (Offsite) | 2-5 € | 72-180 € |
| Monitoring/Uptime-Dienst | 0-10 € | 0-360 € |
| Wartung: 1-2 h × 80-100 € | 80-200 € | 2.880-7.200 € |
| **Realistische Gesamtkosten** | **ca. 90-230 €** | **ca. 3.200-8.200 €** |

Zum Vergleich: [n8n Cloud Pro kostet 50 €/Monat für 10.000 Executions](https://n8n.io/pricing/) - bei monatlicher statt jährlicher Zahlung entsprechend mehr, wotai.co nennt für die Monatsabrechnung 60 $ für den Pro-Plan. Die Ersparnis durch Self-Hosting ist real, aber begrenzt: InstaPods schätzt sie für die meisten Teams auf 200-700 $ pro Jahr gegenüber der Cloud.

Die ehrliche Schlussfolgerung: 6 € pro Monat stimmen nur, wenn deine Zeit nichts kostet. Self-Hosting rechnet sich vor allem dann, wenn die Execution-Zahlen so hoch steigen, dass Cloud-Tarife explodieren würden - [der Business-Plan liegt bereits bei 667 €/Monat für 40.000 Executions](https://n8n.io/pricing/) - oder wenn Datenkontrolle ohnehin Pflicht ist und die Ops-Kapazität bereits existiert.

## DSGVO beim Self-Hosting: Vorteile und Pflichten

![Illustration zur DSGVO-Konformität beim n8n selbst hosten mit EU-Serverstandort und sicher verwahrtem Encryption-Key](/blog/n8n-selbst-hosten-illustration-5.webp)

Self-Hosting löst DSGVO nicht automatisch. Richtig ist: Deine Daten bleiben bei dir, was für DSGVO-konformes Arbeiten ein echter Vorteil ist. Aber Datenhoheit ist eine Startposition, kein Freibrief. Als Verantwortlicher im Sinne der DSGVO trägst du jetzt selbst, was vorher der Cloud-Anbieter vertraglich abdeckte.

Die Praxis-Checkliste für KMU:

- **EU-Serverstandort wählen:** Serverstandort in Deutschland oder Europa - wichtig für die DSGVO. Prüfe zusätzlich, wem der Hoster gehört und wo Support-Zugriffe stattfinden.
- **AVV mit dem Hoster abschließen:** Auch beim reinen Infrastruktur-Hosting verarbeitet der Anbieter Daten in deinem Auftrag. Ohne Auftragsverarbeitungsvertrag fehlt die rechtliche Grundlage.
- **Credentials als kritische Daten behandeln:** In n8n liegen Zugangsdaten zu CRM, E-Mail, Buchhaltung - oft mit personenbezogenen Daten dahinter. Der Encryption-Key entscheidet über deren Sicherheit; regle schriftlich, wer ihn kennt und wo er liegt.
- **Backups verschlüsseln:** Ein unverschlüsselter Postgres-Dump auf einem Dritt-Storage ist ein Datenschutzvorfall in Wartestellung.
- **Löschfristen umsetzen:** n8n speichert Execution-Daten inklusive der durchgelaufenen Nutzdaten. Konfiguriere Data-Pruning, damit personenbezogene Daten nicht unbegrenzt in der Execution-History liegen.
- **Verzeichnis von Verarbeitungstätigkeiten ergänzen:** Die n8n-Instanz mit ihren gespeicherten Credentials und Execution-Daten gehört als eigener Eintrag hinein - das übersehen die meisten.

Wie du Workflows von Anfang an datenschutzkonform gestaltest, zeigt unser Guide [DSGVO-konforme n8n-Automatisierung aufsetzen](/de/blog/n8n-automatisierung-guide/).

## Betrieb absichern: Backup, Update und Monitoring

Der Aufbau ist ein Nachmittag - der Betrieb ist die eigentliche Verpflichtung. Drei Bausteine entscheiden, ob deine Instanz ein Asset oder ein Risiko ist.

**Backups mit echten Befehlen.** Sichere Datenbank und n8n-Volume täglich per Cron, verschlüsselt und offsite:

```bash
#!/bin/bash
  # /opt/n8n/backup.sh - täglich per Cron: 0 3 * * * /opt/n8n/backup.sh
STAMP=$(date +%F)
docker exec postgres pg_dump -U n8n n8n | gzip > /backup/n8n-db-$STAMP.sql.gz
docker run --rm -v n8n_data:/data -v /backup:/backup alpine \
  tar czf /backup/n8n-data-$STAMP.tar.gz /data
  # Verschlüsseln und offsite kopieren (z. B. age/gpg + rclone)
age -r <public-key> -o /backup/n8n-$STAMP.age /backup/n8n-db-$STAMP.sql.gz
```

Und dann der Schritt, den fast alle auslassen: **Teste den Restore.** Spiele den Dump quartalsweise in einen frischen Container ein und prüfe, ob Workflows und Credentials (mit deinem gesicherten Encryption-Key!) funktionieren. Ein ungetestetes Backup ist kein Backup - es ist eine Hoffnung.

**Updates mit Image-Pinning.** Verwende nie `latest` in Produktion. Pinne die Version im Compose-File, lies vor jedem Sprung die Release Notes auf Breaking Changes, ziehe das neue Image, starte den Stack neu - und behalte das alte Tag als Rollback-Option. n8n released hochfrequent; wer blind aktualisiert, riskiert stehende Workflows am Montagmorgen.

**Monitoring.** Ein externer Uptime-Check auf die Webhook-URL, Alerts bei RAM- und Disk-Engpässen, Zugriff auf `docker logs`. Das Ziel ist simpel: Du erfährst vom Ausfall, bevor dein Kunde ihn meldet. Gerade Webhook-basierte Workflows scheitern lautlos - der externe Dienst bekommt einen Timeout, und niemand merkt es.

## Wann Self-Hosting die falsche Wahl ist

Dieser Abschnitt fehlt in fast jedem Hosting-Guide, weil ihn meist Hosting-Anbieter schreiben. Deshalb hier neutrale Kriterien, wann du n8n nicht selbst hosten solltest:

- **Kein internes Ops-Know-how:** Self-Hosting ergibt keinen Sinn, wenn du Server, SSL und Updates nicht verwalten willst - "nicht können" gehört ehrlicherweise dazu.
- **Bus-Faktor 1:** Wenn genau eine Person im Unternehmen den Server versteht, hängt deine Automatisierung an deren Urlaub, Krankheit oder Kündigung. Für Workflows, die Angebote verschicken oder Leads verarbeiten, ist das ein Geschäftsrisiko, kein IT-Detail.
- **Wenige Workflows:** Bei einer Handvoll Automationen frisst die gebundene Ingenieurszeit jede Ersparnis - die TCO-Tabelle oben zeigt warum. Dann fährst du mit [n8n Cloud Starter für 20 €/Monat](https://n8n.io/pricing/) schlicht günstiger.
- **Hohe Compliance-Haftung:** Wer Gesundheits- oder Finanzdaten verarbeitet, braucht dokumentierte Prozesse für Patching, Zugriffskontrolle und Incident Response. Das leistet kein nebenbei betreuter VPS.

Trifft einer dieser Punkte zu, heißt die Antwort nicht automatisch "zurück in die US-Cloud". Der Mittelweg: [n8n als Managed Service betreiben lassen](https://alloq.digital/de/leistungen/ki-automatisierung/n8n-make/) - dedizierte Instanz auf EU-Infrastruktur, mit Backups, Updates und Monitoring als Verantwortung eines Partners statt deines Kalenders. Du behältst die Datenhoheit des Self-Hostings, ohne ein DevOps-Team aufzubauen.

## Entscheidungshilfe: Self-Hosting, Managed oder Cloud

Die Entscheidung in drei Fragen:

**1. Hast du jemanden, der den Betrieb dauerhaft verantwortet - nicht nur das Setup?**
Nein → Self-Hosting scheidet aus. Weiter zu Frage 3.

**2. Verarbeitest du sensible oder personenbezogene Daten, die EU-Kontrolle erfordern?**
Ja + Ops-Kapazität vorhanden → **Self-Hosting.** Volle Kontrolle, unbegrenzte Executions, DSGVO-Setup wie oben beschrieben.

**3. Wie viele Workflows und Executions laufen bei dir?**
Wenige, unkritische Daten → **n8n Cloud.** Der Starter-Tarif ist der schnellste Weg, und Wartung ist komplett abgenommen.
Viele Workflows oder sensible Daten, aber kein Ops-Team → **Managed n8n.** Datenhoheit und EU-Betrieb ohne Wartungslast - der Mittelweg, den [wir bei alloq als Service anbieten](https://alloq.digital/de/leistungen/ki-automatisierung/n8n-make/).

Falls du grundsätzlich noch zwischen Plattformen schwankst, hilft dir unser Vergleich [Make vs. n8n im Kosten- und DSGVO-Vergleich](/de/blog/make-vs-n8n-vergleich/) bei der Einordnung von Operations- gegen Execution-Pricing.

Die Handlungsempfehlung zum Schluss: Rechne deine TCO ehrlich mit deinem eigenen Stundensatz durch, bevor du dich vom 6-€-Versprechen leiten lässt. Wenn Self-Hosting dann noch gewinnt, folge dem Compose-Setup oben - und sichere den Encryption-Key, bevor du den ersten Workflow baust.

## FAQ

### Was kostet n8n selbst gehostet wirklich pro Monat?

Der reine VPS kostet rund 5-6 € pro Monat. Rechnest du Backup-Storage, Monitoring und 1-2 Stunden monatliche Wartung zum internen Stundensatz dazu, liegen die realen Gesamtkosten für KMU eher bei 80-250 € pro Monat. Der größte versteckte Posten ist deine Zeit, nicht der Server.

### Ist selbst gehostetes n8n DSGVO-konform?

Es kann DSGVO-konform sein, wird es aber nicht automatisch. Nötig sind ein EU-Serverstandort, ein AVV mit dem Hoster, verschlüsselte Backups, ein Löschkonzept für Execution-Daten und geregeltes Encryption-Key-Handling. Datenhoheit ist der Vorteil - die Verantwortung dafür trägst du selbst.

### Wie viel RAM und CPU brauche ich für n8n?

Mindestens 2 GB RAM, empfohlen 4 GB - mit Postgres sind 4 GB RAM und 2 vCPU der produktive Sweet Spot. RAM zählt dabei mehr als CPU, weil n8n die meiste Zeit auf externe API-Antworten wartet. Bei vielen parallelen Executions rüstest du auf oder nutzt den Queue-Mode.

### Was passiert mit meinen Credentials, wenn ich den Encryption-Key verliere?

Der N8N_ENCRYPTION_KEY verschlüsselt alle gespeicherten Zugangsdaten - geht er verloren, verlierst du den Zugriff auf sämtliche Credentials. Du müsstest jede Verbindung zu CRM, E-Mail und allen anderen Diensten neu einrichten. Sichere den Key deshalb getrennt vom Server, etwa im Unternehmens-Passwort-Manager.

### Wann sollte ich n8n nicht selbst hosten?

Wenn niemand im Team den Betrieb dauerhaft verantworten kann, du nur wenige Workflows fährst, hohe Compliance-Haftung trägst oder deine Ingenieurszeit teurer ist als die Ersparnis. Für Einsteiger und alle, die keine Server verwalten wollen, ist Self-Hosting ausdrücklich nicht sinnvoll - dann sind Cloud oder Managed n8n wirtschaftlicher.

### Wie mache ich Backups und Updates sicher?

Automatisiere täglich einen verschlüsselten Postgres-Dump plus n8n-Volume-Archiv per Cron und lagere beides offsite. Teste den Restore quartalsweise in einem frischen Container - inklusive Encryption-Key. Updates fährst du mit gepinnter Image-Version statt `latest`, liest vorher die Release Notes und behältst das alte Tag als Rollback.