n8n selbst hosten auf Hetzner (Schritt für Schritt)

Hetzner ist die erste Wahl für deutsches Hosting: Server in Nürnberg oder Falkenstein, faire Preise, exzellente Performance. Ein CX22-Server (4 GB RAM) für 3,99 €/Monat reicht für die meisten n8n-Instanzen.

Der wichtigste Punkt: Self-Hosting ist nicht nur “n8n irgendwo starten”. Eine produktive Installation braucht DNS, TLS, persistente Volumes, Backups, Updates, Zugriffsschutz und einen Plan für Fehlerfälle. Wenn ein Workflow Kontaktanfragen, Rechnungen, CRM-Daten oder Monitoring verarbeitet, ist ein kaputter Container kein kleines Bastelproblem mehr.

Diese Anleitung zeigt deshalb nicht nur den schnellen Start, sondern auch die Entscheidungen, die du vor dem Livegang treffen solltest.

Voraussetzungen

• Hetzner-Konto (hetzner.com)
• Eine Domain, deren DNS du verwalten kannst
• Grundkenntnisse im Umgang mit der Kommandozeile (SSH)
• Einen Passwortmanager für Admin-Zugang, API-Keys und Recovery-Codes
• Eine Entscheidung, ob du mit SQLite startest oder direkt Postgres nutzt

Empfohlenes Setup

Für kleine Teams und erste produktive Workflows ist ein einzelner Hetzner VPS mit Docker Compose, Caddy, persistentem Volume und täglichem Backup oft ausreichend. Für höhere Last, viele parallele Webhooks oder kritische Prozesse solltest du Postgres und später Queue Mode mit Redis prüfen.

Einsatz	Empfehlung
Lerninstanz, wenige Workflows	CX22, Docker Compose, SQLite, Caddy
Kleine Produktivinstanz	CX22/CX32, Docker Compose, Postgres, Backups
Viele Webhooks oder lange Jobs	CX32+, Postgres, Redis, Queue Mode
Kritische Kundenprozesse	Monitoring, Restore-Test, getrennte Staging-Instanz

SQLite ist für den Einstieg bequem. Für produktive Setups ist Postgres meist die bessere Wahl, weil Backups, Migrationen und parallele Nutzung sauberer kontrollierbar sind. Du musst nicht am ersten Tag überarchitektieren, aber du solltest wissen, wann du aus dem Minimalsetup herauswächst.

Schritt 1: Server erstellen

Im Hetzner Cloud Dashboard einen neuen Server anlegen:

• Image: Ubuntu 24.04
• Typ: CX22 (2 vCPU, 4 GB RAM)
• Standort: Nürnberg oder Falkenstein (DE)
• SSH-Key hinterlegen

Setze zusätzlich eine Firewall-Regel:

• Port 22 nur von deiner IP, wenn möglich
• Port 80 und 443 öffentlich
• Port 5678 nicht öffentlich freigeben, wenn Caddy oder nginx davor liegt

Danach legst du einen DNS-Eintrag an:

Typ: A
Name: n8n
Wert: DEINE-SERVER-IP
TTL: Auto

Warte, bis n8n.deine-domain.de auf die Server-IP zeigt. Erst danach kann Caddy zuverlässig TLS-Zertifikate ausstellen.

Schritt 2: Docker installieren

ssh root@DEINE-SERVER-IP

# System aktualisieren
apt update && apt upgrade -y

# Docker installieren
curl -fsSL https://get.docker.com | sh

Lege danach ein Projektverzeichnis an:

mkdir -p /opt/n8n
cd /opt/n8n

Optional, aber sinnvoll: Erstelle einen separaten Nutzer für Wartung und verbiete später Root-SSH. Für den ersten Start ist Root pragmatisch, für dauerhaftes Hosting solltest du Serverhärtung sauber nachziehen.

Schritt 3: docker-compose.yml erstellen

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.deine-domain.de
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.deine-domain.de/
      - GENERIC_TIMEZONE=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Dieses Minimalsetup nutzt das interne n8n-Volume. Für ernsthafte Produktivdaten solltest du mindestens dokumentieren, wo die Daten liegen und wie du sie wiederherstellst. Noch besser ist eine Postgres-Variante:

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

  n8n:
    image: n8nio/n8n:latest
    restart: always
    depends_on:
      - postgres
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.deine-domain.de
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.deine-domain.de/
      - GENERIC_TIMEZONE=Europe/Berlin
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=BITTE_LANGES_PASSWORT_SETZEN
      - N8N_ENCRYPTION_KEY=BITTE_32_ZEICHEN_ODER_LAENGER_SETZEN
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
  postgres_data:

Wichtig ist N8N_ENCRYPTION_KEY. Ohne stabil gesetzten Key riskierst du, dass Credentials nach einem Umzug oder Restore nicht mehr entschlüsselt werden können. Speichere diesen Key nicht nur auf dem Server, sondern sicher im Passwortmanager.

Schritt 4: SSL mit Caddy einrichten

Caddy übernimmt das SSL-Zertifikat automatisch via Let’s Encrypt:

apt install -y caddy

# /etc/caddy/Caddyfile
n8n.deine-domain.de {
    reverse_proxy localhost:5678
}

systemctl reload caddy

Der Compose-Port sollte nur auf 127.0.0.1 gebunden sein, wenn Caddy auf demselben Server läuft. Dann ist n8n nicht direkt über :5678 aus dem Internet erreichbar, sondern nur über HTTPS.

Schritt 5: n8n starten

docker compose up -d

n8n ist jetzt unter https://n8n.deine-domain.de erreichbar. Beim ersten Aufruf richtest du deinen Admin-Account ein.

Prüfe danach:

docker compose ps
docker compose logs -f n8n
curl -I https://n8n.deine-domain.de

Wenn der Browser eine Warnung zeigt, ist meistens DNS noch nicht sauber gesetzt oder Caddy konnte kein Zertifikat ausstellen. Wenn Webhooks später falsche URLs erzeugen, prüfe WEBHOOK_URL, N8N_HOST und N8N_PROTOCOL.

Automatische Updates

# Cronjob für wöchentliche Updates
(crontab -l; echo "0 3 * * 1 docker compose -f /opt/n8n/docker-compose.yml pull && docker compose -f /opt/n8n/docker-compose.yml up -d") | crontab -

Automatische Updates sparen Arbeit, können aber auch Workflows brechen, wenn Nodes, APIs oder n8n-Versionen sich ändern. Für produktive Systeme ist ein kontrollierter Update-Pfad besser:

1. Backup erstellen.
2. Release Notes prüfen.
3. Update auf Staging oder außerhalb kritischer Zeiten einspielen.
4. Wichtigste Workflows manuell testen.
5. Fehlerpfad dokumentieren, falls Rollback nötig ist.

Backups und Restore testen

Ein Backup ist erst dann ein Backup, wenn du es wiederherstellen kannst. Sichere mindestens:

• docker-compose.yml
• .env oder dokumentierte Environment-Variablen
• n8n Volume
• Postgres-Datenbank, falls genutzt
• N8N_ENCRYPTION_KEY

Beispiel für Postgres:

docker compose exec postgres pg_dump -U n8n n8n > /opt/n8n/backups/n8n-$(date +%F).sql

Teste mindestens einmal auf einem separaten Server oder lokal, ob du n8n mit dem Backup starten kannst und Credentials weiterhin funktionieren. Genau hier fallen viele Self-Hosting-Setups durch.

Monitoring und Fehlerbenachrichtigung

Produktive n8n-Workflows brauchen zwei Arten von Monitoring:

• Infrastruktur: Läuft der Server? Läuft Docker? Ist HTTPS erreichbar?
• Workflow-Ebene: Sind kritische Workflows fehlgeschlagen? Bleiben Webhook-Antworten aus?

Pragmatisch startest du mit Uptime-Monitoring für die n8n-URL und einem Error-Workflow in n8n, der Fehler an E-Mail, Slack oder Telegram meldet. Für wichtigere Installationen kommen Systemmetriken, Speicherplatz-Warnungen und Backup-Checks dazu.

DSGVO- und Sicherheitscheck

Self-Hosting in Deutschland ist ein gutes Fundament, aber keine automatische DSGVO-Garantie. Prüfe vor dem Livegang:

• Gibt es einen AVV mit dem Hoster?
• Welche personenbezogenen Daten laufen durch Workflows?
• Wie lange werden erfolgreiche und fehlgeschlagene Executions gespeichert?
• Welche Credentials sind in n8n hinterlegt?
• Wer hat Admin-Zugriff?
• Welche Drittanbieter-Nodes übertragen Daten außerhalb der EU?
• Gibt es ein Löschkonzept für Testdaten und alte Ausführungen?

Besonders wichtig: Viele Teams hosten n8n zwar in Deutschland, schicken Daten dann aber über Slack, Google Sheets oder andere Drittanbieter weiter. Der Serverstandort allein löst dieses Problem nicht.

Wann Queue Mode sinnvoll wird

Queue Mode mit Redis lohnt sich, wenn Workflows lange laufen, viele Webhooks gleichzeitig eintreffen oder die UI nicht durch Worker-Jobs blockiert werden soll. Für kleine Setups ist das zusätzliche Komplexität. Für Agenturen, interne Plattformen oder stark frequentierte Webhooks kann es aber der Unterschied zwischen “läuft meistens” und “läuft belastbar” sein.

Wenn du Queue Mode planst, denke früh über diese Punkte nach:

• separater Redis-Service
• mehrere Worker
• saubere Prozessüberwachung
• Logging pro Worker
• Backups und Restore für Postgres
• klare Deployments statt spontaner Container-Updates

Fazit

Du hast jetzt eine self-hosted n8n-Instanz auf deutschem Boden - ohne laufende Lizenzkosten und mit guter Grundlage für DSGVO-bewusste Workflows. Für Lernprojekte reicht das Minimalsetup. Für produktive Automatisierung brauchst du zusätzlich Backups, Monitoring, Update-Prozess, Credential-Konzept und Datenschutzprüfung.

Wenn du n8n nicht nur installieren, sondern produktiv mit Backups, Monitoring und Datenschutzkonzept betreiben willst, findest du hier die passende n8n Beratung & Umsetzung.