Ratgeber

n8n self-hosted: Anleitung für Unternehmen

n8n auf eigenem Server betreiben: Voraussetzungen, Einrichtung, Absicherung, Backup und Updates — praxisnah zusammengefasst.

Erstgespräch vereinbaren +49 174 164 5727

n8n self-hosted: Anleitung für Unternehmen

n8n self-hosted läuft auf jedem Server mit Docker — für die meisten Unternehmen reicht ein kleiner VPS mit zwei CPU-Kernen und vier Gigabyte Arbeitsspeicher für 10 bis 30 Euro im Monat. Das Werkzeug verbindet Abläufe zwischen Anwendungen, ohne dass man für jede Verbindung eigenen Code schreibt. Es selbst zu betreiben ist einfacher als sein Ruf, es zuverlässig zu betreiben aufwendiger, als die meisten Anleitungen suggerieren — den Unterschied machen wenige Schritte bei Absicherung, Backup und Updates aus.

Voraussetzungen

Wenig Hardware, aber ein paar feste Anforderungen, an denen man nicht sparen sollte.

Server und Ressourcen

Ein Server mit Docker. Für die meisten Anwendungen reicht ein kleiner VPS bei einem deutschen Anbieter — zwei CPU-Kerne, vier Gigabyte Arbeitsspeicher, für 10 bis 30 Euro monatlich. Ein VPS ist ein virtueller Server, den man allein nutzt, im Gegensatz zum geteilten Webhosting.

EinsatzCPURAMRichtpreis/Monat
Einstieg, wenige Abläufe2 Kerne4 GB10–15 €
Regelbetrieb, mehrere parallel4 Kerne8 GB20–40 €
Hohes Volumen + lokale Modelle8 Kerne16 GB+ab 60 €

Domain und Verschlüsselung

Dazu eine Subdomain und ein TLS-Zertifikat. Beides ist Standard und mit gängigen Reverse-Proxies automatisiert — ein Zertifikat von Let’s Encrypt wird dabei automatisch bezogen und erneuert. Ein Reverse Proxy ist der vorgeschaltete Dienst, der Anfragen entgegennimmt und verschlüsselt an n8n weiterreicht.

Warum Shared Hosting ausscheidet

Klassisches Webhosting kann n8n nicht betreiben, weil n8n einen dauerhaft laufenden Prozess braucht. Shared Hosting startet Programme nur bei einer Anfrage und beendet sie danach — für zeitgesteuerte oder wartende Abläufe ungeeignet. Das ist kein Konfigurationsproblem, sondern eine Grenze des Hosting-Modells.

Felix Wilhelm prüft am Bildschirm einen Ablauf aus verbundenen Schritten

Die Einrichtung Schritt für Schritt

Fünf Schritte, von denen der letzte am häufigsten fehlt.

Grundinstallation

  1. Server aufsetzen, Docker installieren, Firewall konfigurieren (nur 80/443 offen).
  2. n8n über Docker Compose starten, mit persistentem Datenverzeichnis.
  3. Reverse Proxy mit automatischem Zertifikat davorschalten.
  4. Zugangsschutz aktivieren — ohne Authentifizierung ist die Instanz offen im Netz.
  5. Datenbank auf PostgreSQL umstellen, statt der Standard-Dateidatenbank.

Eine minimale docker-compose.yml mit PostgreSQL und gesetztem Verschlüsselungsschlüssel:

services:
  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.de
      - N8N_PROTOCOL=https
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PASSWORD=${PG_PASSWORD}
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [postgres]
  postgres:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${PG_PASSWORD}
      - POSTGRES_DB=n8n
    volumes:
      - ./pg-data:/var/lib/postgresql/data

Gestartet wird das Ganze im Verzeichnis der Datei mit einem Befehl:

docker compose up -d

Der oft ausgelassene Schritt

Punkt 5 wird häufig übergangen und rächt sich, sobald mehrere Abläufe parallel laufen: Die Standard-Dateidatenbank kommt bei gleichzeitigen Ausführungen an ihre Grenzen. Die Umstellung auf PostgreSQL von Anfang an erspart eine spätere Migration — die im laufenden Betrieb deutlich unangenehmer ist als die saubere Einrichtung zu Beginn.

Was zum Betrieb dazugehört

Die Einrichtung ist der Anfang, nicht das Ziel. Drei Dinge trennen den verlässlichen Betrieb vom Glücksspiel.

Backup und Verschlüsselungsschlüssel

Gesichert werden müssen die Datenbank und die Verschlüsselungsschlüssel. Ohne den Schlüssel (N8N_ENCRYPTION_KEY) sind die gespeicherten Zugangsdaten nach einer Wiederherstellung unbrauchbar — der häufigste teure Fehler. Ein einfacher Sicherungsbefehl für die Datenbank:

docker compose exec postgres \
  pg_dump -U n8n n8n | gzip > backup-$(date +%F).sql.gz

Der Schlüssel selbst gehört getrennt und sicher abgelegt, nicht nur ins selbe Backup. Wer beides am selben Ort lagert, verliert im Ernstfall beides zugleich.

Updates und Überwachung

Updates. n8n entwickelt sich schnell. Ein ungepflegtes System ist nach einigen Monaten ein Sicherheitsrisiko. Sinnvoll ist ein fester Turnus statt „wenn Zeit ist”. Ein Update läuft im Kern so:

docker compose pull && docker compose up -d

Überwachung. Fehlgeschlagene Ausführungen müssen jemanden erreichen. Ohne Benachrichtigung fällt ein Ausfall erst auf, wenn ein Kunde nachfragt.

Zugriffsprotokoll. Wer hat wann welchen Ablauf geändert? In der Community-Edition eingeschränkt — bei mehreren Bearbeitern ein Argument für eine höhere Lizenzstufe.

Der Aufwand in Zahlen

AufgabeTurnusAufwand
Backup prüfenmonatlich15 Min.
Update einspielenquartalsweise30–60 Min.
Benachrichtigung testenquartalsweise15 Min.

Der wichtige Hinweis zu KI-Schritten

Ein Missverständnis, das Datenschutzprüfungen scheitern lässt — und das gerade bei Self-Hosting naheliegt.

Self-hosted heißt nicht datenlokal

Selbst gehostet heißt nicht automatisch, dass keine Daten das Haus verlassen. Sobald ein Ablauf ein Sprachmodell über eine Schnittstelle aufruft, gehen die Inhalte dorthin — auch wenn n8n selbst auf dem eigenen Server läuft. Was einen solchen Aufruf konform macht, steht unter DSGVO-konforme KI.

Der lokale Ausweg

Wer das vermeiden muss, kombiniert n8n mit lokal betriebenen Modellen — technisch problemlos, mit Abstrichen bei der Modellqualität. Ein lokal laufendes Modell verarbeitet die Inhalte auf demselben Server und schickt nichts nach außen.

Wann sich das nicht lohnt

Ehrlich abgewogen, ist Self-Hosting nicht immer die richtige Wahl.

Die Aufwandsfrage

Wenn im Haus niemand Zeit für Updates und Backups hat und auch keine externe n8n-Agentur damit beauftragt wird, ist die Cloud-Variante trotz höherer laufender Kosten die ehrlichere Wahl. Die vermeintliche Ersparnis des Selbstbetriebs kehrt sich um, sobald ein ungepflegtes System zum Sicherheitsvorfall wird.

Wann Self-Hosting die richtige Wahl ist

Sinnvoll wird der Eigenbetrieb, wenn ohnehin technisches Personal vorhanden ist, wenn viele Abläufe laufen oder wenn der Datenschutz lokale Modelle verlangt. Dann überwiegt der Vorteil aus Kontrolle und planbaren Kosten. Eine Einordnung der Gesamtkosten gibt der Überblick was KI kostet; für die Entscheidung im konkreten Fall ist das Erstgespräch der schnellste Weg.

Quellen: n8n-Dokumentation · Bundesamt für Sicherheit in der Informationstechnik (BSI)

Häufige Fragen

Reicht Shared Hosting?

Nein. n8n braucht einen dauerhaft laufenden Prozess, das kann klassisches Webhosting nicht.

Wie viel Wartungsaufwand entsteht?

Bei stabilem Betrieb wenige Stunden im Quartal — vorausgesetzt, Backup und Benachrichtigung sind eingerichtet.

Welchen Server braucht n8n?

Einen Server mit Docker — für die meisten Anwendungen reicht ein kleiner VPS bei einem deutschen Anbieter mit zwei CPU-Kernen und vier Gigabyte Arbeitsspeicher für 10 bis 30 Euro monatlich. Dazu kommen eine Subdomain und ein TLS-Zertifikat, beides mit gängigen Reverse-Proxies automatisiert.

Was muss bei n8n gesichert werden?

Die Datenbank und der Verschlüsselungsschlüssel (N8N_ENCRYPTION_KEY). Ohne den Schlüssel sind die gespeicherten Zugangsdaten nach einer Wiederherstellung unbrauchbar — der häufigste teure Fehler. Der Schlüssel gehört getrennt vom Backup abgelegt, sonst verliert man im Ernstfall beides zugleich.

Ist n8n self-hosted automatisch DSGVO-konform?

Nein. Sobald ein Ablauf ein Sprachmodell über eine Schnittstelle aufruft, gehen die Inhalte dorthin — auch wenn n8n selbst auf dem eigenen Server läuft. Wer das vermeiden muss, kombiniert n8n mit lokal betriebenen Modellen, die die Inhalte auf demselben Server verarbeiten.

Wann ist die Cloud-Variante die bessere Wahl?

Wenn im Haus niemand Zeit für Updates und Backups hat und auch niemand extern damit beauftragt wird. Die vermeintliche Ersparnis des Selbstbetriebs kehrt sich um, sobald ein ungepflegtes System zum Sicherheitsvorfall wird — dann ist die Cloud trotz höherer laufender Kosten die ehrlichere Wahl.