Workflow-Automatisierung

n8n selbst hosten: Setup-Anleitung mit Docker Compose

n8n auf eigenem Server mit Docker Compose: was das Setup kostet, was es braucht und wo die echten Fallstricke liegen.

Johannes · 13. März 2026

Wer n8n selbst hosten will und dabei seine Daten behält, setzt Docker Compose ein. Ein VPS kostet 10–15 € monatlich – egal wie viele Workflows laufen oder wie oft sie ausgeführt werden. Diese Anleitung zeigt das Setup mit Docker Compose, PostgreSQL und Caddy – plus die Fallstricke, die euch beim ersten Neustart überraschen.

Isometrischer Wuerfel aus blauen Gitterlinien beim Aufbau, untere Schichten solid, obere transparent — Isometrische Darstellung eines Würfels aus blauen Gitterlinien beim Aufbau, mit soliden unteren und transparenten oberen Schichten.

Voraussetzungen

Linux-Server (VPS oder On-Premise), mindestens 2 vCPU und 2 GB RAM. Empfohlen: 4 GB RAM für stabileren Betrieb.
Docker Engine ≥ 24 + Docker Compose v2 (docker compose version prüft das)
Öffentlich erreichbare Domain (z. B. n8n.meinunternehmen.at) mit A-Record auf den Server (DNS muss zeigen, damit n8n erreichbar ist)
SSH-Zugang mit sudo-Rechten

Verzeichnisstruktur

Alle Dateien kommen in ein eigenes Verzeichnis – zum Beispiel /opt/n8n/:

/opt/n8n/
├── docker-compose.yml
├── Caddyfile
└── .env

Secrets in die .env-Datei

Passwörter und Keys gehören nicht direkt in die docker-compose.yml. Legen Sie eine .env-Datei im selben Verzeichnis an – Docker Compose lädt sie automatisch:

# Datenbank
POSTGRES_USER=n8n_user
POSTGRES_PASSWORD=langes_zufaelliges_passwort_hier

# n8n Verschlüsselung
N8N_ENCRYPTION_KEY=mind_32_zeichen_langer_zufaelliger_schluessel

# n8n Konfiguration für Reverse Proxy
N8N_HOST=n8n.meinunternehmen.at
N8N_PROTOCOL=https
N8N_PORT=5678
N8N_EDITOR_BASE_URL=https://n8n.meinunternehmen.at
WEBHOOK_URL=https://n8n.meinunternehmen.at/

# Zeitzone (für Cron-Workflows wichtig!)
GENERIC_TIMEZONE=Europe/Vienna
TZ=Europe/Vienna

# Ausführungsdaten bereinigen (DB-Wachstum verhindern)
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336

Den N8N_ENCRYPTION_KEY unbedingt sichern und nicht verlieren – er verschlüsselt alle in n8n gespeicherten Credentials. Ohne ihn sind nach einem Neustart mit neuem Container sämtliche Zugangsdaten unbrauchbar. Einen zufälligen Key erzeugt openssl rand -hex 32.

Wichtige Variablen:

GENERIC_TIMEZONE & TZ: Ohne diese laufen Cron-Workflows in UTC statt in eurer lokalen Zeit. Das ist ein häufiger Fehler.
N8N_PROTOCOL, N8N_PORT, N8N_EDITOR_BASE_URL: Damit n8n mit dem Reverse Proxy hinter sich richtig funktioniert. N8N_EDITOR_BASE_URL ist essentiell, sonst zeigt die Web-UI interne Container-URLs.
EXECUTIONS_DATA_PRUNE & MAX_AGE: Sonst wächst die Datenbank unbegrenzt. Ohne diese Option speichert n8n jeden Workflow-Run ewig.

docker-compose.yml

Docker Compose v2 benötigt kein version:-Feld mehr – das wurde als obsolet markiert:

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_HOST=${N8N_HOST}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - N8N_PORT=${N8N_PORT}
      - N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${TZ}
      - EXECUTIONS_DATA_PRUNE=${EXECUTIONS_DATA_PRUNE}
      - EXECUTIONS_DATA_MAX_AGE=${EXECUTIONS_DATA_MAX_AGE}
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n-data:/home/node/.n8n

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

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

volumes:
  n8n-data:
  postgres-data:
  caddy-data:
  caddy-config:

Caddy Reverse Proxy Konfiguration

Das ist der kritischste Schritt – und wird oft übersehen. Caddy braucht einen Proxy-Block, damit n8n von außen erreichbar ist. Ohne diesen funktioniert das gesamte Setup nicht.

Erstellen Sie die Datei /opt/n8n/Caddyfile:

n8n.meinunternehmen.at {
    reverse_proxy n8n:5678
}

Das ist alles, was ihr braucht. Caddy kümmert sich um:

HTTPS-Zertifikat (automatisch via Let's Encrypt)
Port 80 → 443 Umleitung
Request-Forwarding zu n8n Container auf Port 5678

Voraussetzung: Euer DNS A-Record muss auf die Server-IP zeigen.

Caddy Persistenz (Volumes)

Die zwei Volumes für Caddy sind wichtig:

caddy-data: Speichert die TLS-Zertifikate. Beim Neustart löscht Caddy sonst die Let's Encrypt-Certs und fordert neue an – das Rate-Limit wird schnell erreicht.
caddy-config: Speichert die Caddyfile-Konfiguration und Admin-API-State.

Starten und prüfen

Aus dem Verzeichnis /opt/n8n/ heraus:

# Container starten
docker compose up -d

# Status prüfen
docker compose ps

# Logs beobachten
docker compose logs -f n8n

Beim ersten Aufruf von https://n8n.meinunternehmen.at fragt n8n nach einem Owner-Account. Dieser Account ist der Administrator der Instanz. Die alten Basic-Auth-Umgebungsvariablen (N8N_BASIC_AUTH_ACTIVE u. ä.) gibt es seit n8n 1.0 nicht mehr – das integrierte User-Management hat sie abgelöst.

Updates durchführen

Regelmäßige Updates sind wichtig für Sicherheit und Stabilität. Am einfachsten geht es mit:

# Neue Images downloaden
docker compose pull

# Container mit neuen Images starten
docker compose up -d

# Alte Images aufräumen
docker image prune -a -f

Alternativ könnt ihr auch automatisierte Update-Tools nutzen:

Watchtower: Prüft automatisch auf neue Image-Versionen und startet Container neu. Sinnvoll, wenn ihr ein regelmäßiges Patch-Fenster habt.
Renovate: Erstellt automatisch PRs für neue Versions-Tags im compose.yml. Gibt euch die Kontrolle – ihr reviewed Updates, bevor sie deployed werden.

Tipp: Pinnt die Image-Versionen in der docker-compose.yml, z.B. n8nio/n8n:1.45.0 statt latest. Das verhindert unerwartete Major-Version-Updates.

Backup

Alle Workflows und Credentials liegen in PostgreSQL. Ein täglicher Backup ist essentiell.

#!/bin/bash
# /opt/n8n/backup.sh
# Backup script für n8n

BACKUP_DIR="/backups"
N8N_DIR="/opt/n8n"
DATE=$(date +%F_%H-%M-%S)

# Datenbank
cd $N8N_DIR
/usr/bin/docker compose exec -T postgres pg_dump -U n8n_user -F c n8n > $BACKUP_DIR/n8n_db_$DATE.dump

# .env (credentials!)
cp $N8N_DIR/.env $BACKUP_DIR/n8n_env_$DATE.bak

# Caddyfile (configuration)
cp $N8N_DIR/Caddyfile $BACKUP_DIR/n8n_caddyfile_$DATE.bak

echo "Backup completed: $BACKUP_DIR/n8n_*_$DATE*"

Script-Besonderheiten:

Voller Pfad zu /usr/bin/docker compose: Cron-Jobs haben oft nicht den ganzen PATH – damit läuft es auch im Cron-Kontext.
Sichert nicht nur die DB, sondern auch .env und Caddyfile: Diese werden oft vergessen, sind aber für einen vollständigen Restore essentiell.
Format -F c: Komprimiertes Dump-Format, kann mit pg_restore selektiv wiederhergestellt werden.

Cron-Eintrag (täglich um 3:00 Uhr, in /etc/cron.d/n8n-backup):

0 3 * * * root /opt/n8n/backup.sh >> /var/log/n8n-backup.log 2>&1

Remote Backup – Das Wichtigste!

Lokale Backups auf dem gleichen Server sind nicht genug. Wenn der Server komplett ausfällt, Festplatte stirbt oder gehackt wird – die Backups sind weg. Ihr müsst die Backups an einen anderen Ort pushen.

Option 1: Hetzner Storage Box (BorgBackup)

Hetzner bietet bis 1 TB Storage Box ab ~4 € monatlich. BorgBackup ist einfach und zuverlässig:

#!/bin/bash
# Zu /opt/n8n/backup.sh hinzufügen (nach der lokalen Backup-Sektion):

# Remote Backup zu Hetzner Storage Box
BORG_REPO="ssh://[email protected]/backup/n8n"
BORG_PASSPHRASE="hier-ein-starkes-passwort"

export BORG_REPO BORG_PASSPHRASE

# BorgBackup archivieren (dedupliziert automatisch)
borg create --progress --stats \
  ::n8n-{now:%Y-%m-%d_%H:%M:%S} \
  $BACKUP_DIR/

# Alte Backups löschen (älter als 30 Tage)
borg prune --keep-daily=30 --progress

echo "Remote backup synced to Hetzner Storage Box"

Option 2: S3 oder S3-kompatibel (AWS, MinIO, Wasabi)

Für mehr Flexibilität. AWS S3 kostet ~0,023 $/GB/Monat, Wasabi (S3-kompatibel, Europa-basiert) ist günstiger. Installation: apt install awscli oder pip install boto3.

#!/bin/bash
# Zu /opt/n8n/backup.sh hinzufügen (nach der lokalen Backup-Sektion):

# AWS S3 Upload
AWS_ACCESS_KEY_ID="your-access-key"
AWS_SECRET_ACCESS_KEY="your-secret-key"
S3_BUCKET="my-n8n-backups"
S3_REGION="eu-central-1"  # Oder deine Region

export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY

# Alle Backup-Dateien zu S3 uploaden
aws s3 sync $BACKUP_DIR s3://$S3_BUCKET/$(date +%Y-%m-%d)/ \
  --region $S3_REGION \
  --sse AES256

# Optional: alte Backups aus S3 löschen (älter als 30 Tage)
aws s3 rm s3://$S3_BUCKET \
  --recursive \
  --exclude "*" \
  --include "*" \
  --region $S3_REGION \
  --older-than-days 30

echo "Backup synced to S3"

Für Wasabi (S3-kompatibel, günstiger, EU-Host): Endpoint-URL anpassen:

# Wasabi Endpoint statt AWS
aws s3 sync $BACKUP_DIR s3://$S3_BUCKET/$(date +%Y-%m-%d)/ \
  --endpoint-url https://s3.eu-central-1.wasabisys.com \
  --region eu-central-1 \
  --sse AES256

Für KMUs empfohlen:

Kleine Backups (<100 GB): Hetzner Storage Box + BorgBackup (einfach, zuverlässig, günstig).
Größere oder kritische Setups: Wasabi S3 (Europa-basiert, DSGVO-konform, schnell, flexibel).
Hybrid: Tägliches Backup zu Storage Box, wöchentlich zu S3. Das gibt euch Redundanz und schnelle Recovery.

Security Hardening

Ein n8n Setup mit Webhooks ist offen für das Internet. Diese Maßnahmen minimieren Risiken:

Firewall: Exponiert nur Port 80/443 (Caddy). SSH auf non-standard Port (z.B. 2222). Rest blockiert.
Fail2ban: Blockiert IP-Adressen nach mehreren Failed-Login-Versuchen. Relevant für n8n Web-UI und SSH.
Cloudflare DDoS Protection: Wenn eure Domain über Cloudflare läuft, nutzt deren DDoS-Schutz und Firewall-Rules.
SSH-Hardening: SSH-Passwort-Auth deaktivieren, nur Key-basierte Auth. Non-standard Port. Root-Login verhindern.

Queue Mode für Produktions-Setups

Für viele parallele Workflows oder zeitkritische Prozesse ist Queue Mode sinnvoll. Redis fungiert als Message Broker, Worker-Container verarbeiten Jobs asynchron:

# In docker-compose.yml hinzufügen:
# N8N_EXECUTIONS_MODE=queue
# N8N_REDIS_HOST=redis
# N8N_REDIS_PORT=6379

# Redis Service:
redis:
  image: redis:7-alpine
  restart: unless-stopped
  healthcheck:
    test: ["CMD", "redis-cli", "ping"]
    interval: 10s
    timeout: 5s
    retries: 5

Monitoring

n8n bietet einen Health-Check-Endpoint unter /healthz, der sich leicht in externe Monitoring-Tools (z. B. Uptime Kuma oder Grafana) einbinden lässt. Für PostgreSQL-Metriken kann Prometheus mit dem postgres_exporter angebunden werden.

Österreich-Spezifisches

DSGVO-Checkliste: Stellen Sie sicher, dass keine personenbezogenen Daten außerhalb der EU gespeichert werden. Empfohlene Anbieter: Hetzner (Deutschland) oder A1 Cloud (Österreich). Hinweis: EU-Hosting ist empfohlen, aber nicht zwingend – Standard Contractual Clauses und EU-US Data Privacy Framework erlauben auch US-basierte Services, wenn entsprechende Verträge bestehen.
Förderungen: aws – Austria Wirtschaftsservice und KMU.DIGITAL fördern Digitalisierungsprojekte österreichischer KMU – Self-Hosting-Infrastruktur kann förderfähig sein.
Managed Hosting: breida bietet Managed-Hosting-Pakete für n8n inkl. SLA, Backup-Management und regelmäßiger Sicherheits-Audits – für KMU, die den Betrieb nicht intern abdecken wollen.

Community Edition vs. Enterprise: Was KMUs wissen sollten

n8n Community Edition reicht für die meisten KMUs völlig aus. Hier ist, wo die Unterschiede liegen:

Zugriffskontrolle: In der CE haben alle User die gleichen Rechte – alle können alle Workflows editieren/löschen. Separate Spaces gibt es ab Version 1.7, aber auch dort keine Workflow-Level Permissions. Das ist okay, wenn nur 1-2 Personen n8n nutzen oder wenn User sich gegenseitig vertrauen.
Keine Audit Logs: Wer hat wann welchen Workflow geändert? In der CE seht ihr das nicht. Für KMUs ohne strikte Compliance-Anforderungen ist das unkritisch.
Keine SSO/SAML: Benutzer müssen sich separat in n8n registrieren. Kein Active Directory oder Azure AD Integration. Das ist selten ein Problem für kleine Teams.
Kein External Secrets Management: Credentials werden lokal in der PostgreSQL-Datenbank verschlüsselt (mit dem N8N_ENCRYPTION_KEY). Das ist ausreichend sicher.
Keine Source Control Integration: Ihr könnt Workflows nicht direkt aus Git deployen. Aber: Export/Import über n8n CLI und API-Deployment sind möglich, wenn auch nicht nativ. Workflows müssen manuell oder über die API deployt werden. Backup via Datenbank bleibt die Standardlösung.
Begrenzte Support-Optionen: Community Edition hat keinen offiziellen SLA. Support erfolgt über Community-Forum und Docs.

Die Antwort ist klar: Für KMUs mit bis zu ~20 internen Benutzern ist die CE vollkommen ausreichend. Erst wenn mehrere Teams unabhängig voneinander arbeiten oder strikte Compliance-Anforderungen existieren (z. B. Audit-Logs für Finanz-Prozesse), lohnt sich ein Upgrade zu Enterprise.

Interessiert an einer individuellen n8n-Beratung?

Wir unterstützen Sie beim Aufbau, der Sicherung und dem Betrieb Ihrer n8n-Instanz.

Erstgespräch buchen

Fazit

Docker Compose funktioniert stabil. Updates und Backups macht ihr selbst – das ist der Preis dafür, dass ihr die Kontrolle habt. Die häufigsten Fehler beim Setup: Caddy Reverse Proxy nicht konfigurieren, WEBHOOK_URL vergessen oder den Encryption Key verlieren. Wer diese Sachen im Griff hat, hat eine robuste Plattform, die skaliert, ohne dass die Lizenzkosten mitlaufen.

Häufige Fragen

Welche technischen Voraussetzungen brauche ich für n8n Self-Hosting?

Ein Linux-Server mit Docker und Docker Compose, eine Domain für HTTPS, und grundlegende Linux-Kenntnisse. Für den Start reichen 2 GB RAM und 2 vCPUs.

Ist n8n Self-Hosting DSGVO-konform?

Ja, wenn der Server in der EU steht. Ihre Prozessdaten verlassen nie Ihre Infrastruktur. Empfohlene Anbieter: Hetzner (Deutschland) oder Cloudscale (Schweiz).

Was kostet n8n Self-Hosting im Vergleich zur Cloud?

Ein VPS kostet 15 bis 30 Euro pro Monat, unabhängig von der Anzahl der Ausführungen. n8n Cloud beginnt bei etwa 20 Euro, skaliert aber mit jedem Workflow und jeder Ausführung nach oben.

Wie läuft das Backup bei selbst-gehostetem n8n?

Alle Daten liegen in PostgreSQL. Ein tägliches Datenbank-Dump in ein verschlüsseltes Archiv ist die Standardlösung und lässt sich einfach per Cron-Job automatisieren.

Was ist Queue Mode bei n8n?

Queue Mode schaltet Redis als Message Broker dazwischen und verteilt Workflow-Ausführungen auf separate Worker-Container. Sinnvoll ab etwa 50 gleichzeitigen Workflows oder zeitkritischen Prozessen.