n8n selbst hosten: ein Setup, das auch nach sechs Monaten noch läuft

Die n8n-Cloud ist bequem. Sobald aber Kundendaten, Rechnungen oder Personalakten durch die Workflows laufen, fragen Geschäftsführung und Datenschutzbeauftragter dasselbe: Wo liegt das eigentlich? Dann führt der Weg zum eigenen Server. Hier ist das Setup, das wir bei Kunden ausrollen — und die drei Stellen, an denen es sonst kippt.

Was Sie brauchen

  • Ein kleiner Linux-Server, 2 vCPU und 4 GB RAM reichen für die meisten Betriebe. Bei uns läuft das meist bei einem deutschen Hoster.
  • Eine Subdomain, zum Beispiel automation.ihrefirma.de, mit A-Record auf die Server-IP.
  • Docker und Docker Compose. Sonst nichts.

Der wichtigste Entscheid: nicht SQLite

n8n startet standardmäßig mit SQLite. Das funktioniert am ersten Tag und wird später zum Problem: Bei parallelen Ausführungen und wachsender Ausführungshistorie wird die Datei langsam, und ein Backup im laufenden Betrieb ist heikel. Nehmen Sie von Anfang an Postgres. Ein späterer Wechsel bedeutet Migration bei laufenden Workflows — das will niemand zweimal machen.

docker-compose.yml

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: db
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${DB_PASSWORD}
      N8N_HOST: automation.ihrefirma.de
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://automation.ihrefirma.de/
      GENERIC_TIMEZONE: Europe/Berlin
      TZ: Europe/Berlin
      N8N_ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "336"
      N8N_RUNNERS_ENABLED: "true"
    volumes:
      - n8n:/home/node/.n8n

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

volumes:
  db:
  n8n:
  caddy:

Dazu ein zweizeiliges Caddyfile, das sich das Let's-Encrypt-Zertifikat selbst holt:

automation.ihrefirma.de {
  reverse_proxy n8n:5678
}

Und eine .env mit DB_PASSWORD und ENCRYPTION_KEY — beides lange Zufallswerte, etwa aus openssl rand -hex 32. Danach docker compose up -d, Subdomain aufrufen, Admin-Konto anlegen. Das ist der 20-Minuten-Teil.

Der Schlüssel

N8N_ENCRYPTION_KEY verschlüsselt alle gespeicherten Zugangsdaten. Geht er verloren, sind sämtliche Credentials in allen Workflows unbrauchbar und müssen neu eingegeben werden. Legen Sie ihn in den Passwortmanager, bevor Sie weiterlesen — nicht danach.

Backup: zwei Dinge, nicht eins

Ein Snapshot der virtuellen Maschine ist kein Backup einer laufenden Datenbank. Sichern Sie stattdessen zwei Dinge getrennt und täglich per Cron:

  1. Einen Postgres-Dump: docker compose exec -T db pg_dump -U n8n n8n | gzip > n8n-$(date +%F).sql.gz
  2. Das Volume n8n — dort liegen unter anderem der Schlüssel und lokale Dateien.

Dann das Wichtigste: einmal eine Wiederherstellung auf einem Testserver durchspielen. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.

Drei Fehler, die wir alle einmal gemacht haben

1. Ausführungshistorie läuft voll

Ohne EXECUTIONS_DATA_PRUNE speichert n8n jede Ausführung mit allen Daten. Bei einem Workflow, der alle fünf Minuten läuft, ist die Platte in wenigen Monaten voll und die Oberfläche träge. Zwei Wochen Historie (336 Stunden) reichen in der Praxis fast immer.

2. Webhook-URL falsch gesetzt

Wenn WEBHOOK_URL nicht auf die öffentliche HTTPS-Adresse zeigt, generiert n8n interne URLs, die Fremdsysteme nicht erreichen. Das fällt erst auf, wenn der erste externe Dienst nicht zurückruft — meist beim Kunden im Livebetrieb.

3. Kein Error-Workflow

Standardmäßig scheitert ein Workflow still. Bauen Sie einen einzigen Error-Workflow, der Fehler per Mail oder Chat meldet, und tragen Sie ihn in den Einstellungen jedes produktiven Workflows ein. Ohne das merken Sie Ausfälle erst, wenn ein Kunde anruft.

Wann Queue-Mode?

Solange Workflows nur ein paar Mal pro Minute starten, genügt die Einzelinstanz. Sobald mehrere lange Ausführungen parallel laufen — Dokumentverarbeitung, KI-Aufrufe mit Wartezeit, größere Importe — trennen Sie Main-Prozess und Worker über Redis (EXECUTIONS_MODE=queue). Das ist kein Anfänger-Setup, aber der Grund, warum man Postgres von Beginn an nimmt: Der Schritt ist dann eine Konfigurationsänderung, keine Migration.

Was das kostet

Ein passender Server liegt je nach Anbieter im einstelligen bis niedrigen zweistelligen Euro-Bereich pro Monat. n8n selbst ist in der Community-Edition kostenlos, solange Sie es intern nutzen und nicht als Dienst weiterverkaufen. Der eigentliche Aufwand ist nicht der Server, sondern das Danach: Updates, Monitoring und jemand, der bei einem Fehlerlauf hinschaut.

Lieber nicht selbst betreiben?

Wir hosten n8n auf Servern in Deutschland oder in Ihrem Netz, mit Monitoring, Updates und Backup-Test — ab 49 € pro Monat. Sie bauen Workflows, wir halten die Basis am Laufen.

Hosting anfragen Preise ansehen
Weiterlesen