So hostest du n8n selbst (Leitfaden 2026)

Selbsthosting von n8n gibt dir die vollständige Workflow-Automatisierungsplattform ohne Ausführungslimits und mit vollständigem Eigentum an deinen Daten. Diese Anleitung geht ehrlich durch die echte Docker-, Docker-Compose- und PostgreSQL-Einrichtung und zeigt dann die Abkürzung in 30 Sekunden, falls du die Serveradministration lieber ganz überspringst.

Was bedeutet „n8n selbst hosten“?

n8n ist ein Workflow-Automatisierungstool mit offenem Quellcode. Anders als n8n Cloud, das vom n8n-Team betriebene gehostete SaaS, heißt Selbsthosting: du betreibst die n8n-Anwendung auf einer Infrastruktur, die du kontrollierst. Die Software selbst ist unter einer Fair-Code-Lizenz kostenlos, aber Rechenleistung, Datenbank, Speicher und Bandbreite für den Betrieb 24/7 sind es nicht. Selbsthosting ist die richtige Wahl, wenn du keine Ausführungslimits willst, volle Kontrolle über Zugangsdaten und Daten, unbegrenzte Workflows und die Möglichkeit, Community-Nodes und eigenen Code ohne SaaS-Stufe zu nutzen.

n8n-Systemanforderungen

n8n ist zum Start schlank, skaliert aber damit, wie schwer deine Workflows sind. Eine realistische Basis:

• CPU: 1 vCPU reicht für leichte Nutzung; 2+ vCPU für viele gleichzeitige Ausführungen.
• RAM: 1 bis 2GB für n8n. Workflows, die große Payloads verarbeiten (Dateien, Bilder, großes JSON), brauchen mehr.
• Datenbank: PostgreSQL wird für die Produktion dringend empfohlen. Das standardmäßige SQLite funktioniert zum Testen, kommt aber schlecht mit Parallelität zurecht und ist schwerer sicher zu sichern.
• Speicher: Ein paar GB reichen zum Start; Ausführungsverlauf und Binärdaten wachsen mit der Zeit.
• Netzwerk: Ein öffentlicher HTTPS-Endpunkt (Port 443), damit eingehende Webhooks und OAuth-Callbacks funktionieren.

Eine tiefere Aufschlüsselung nach Tarifgrößen findest du in unserer Leitfaden zu n8n-Server-Anforderungen.

Option 1: n8n mit Docker bereitstellen

Der schnellste Weg, n8n auf deiner eigenen Maschine oder deinem VPS zu betreiben, ist das offizielle Docker-Image. Das ist ideal für einen lokalen Test, aber beachte, dass es SQLite nutzt und kein TLS hat: nichts, was du in der Produktion willst:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Öffne http://localhost:5678, lege das Besitzerkonto an, und du hast ein funktionierendes n8n. Für alles Ernsthafte wechsle zu Docker Compose mit PostgreSQL.

Option 2: Docker Compose mit PostgreSQL

Ein Produktions-Setup kombiniert n8n mit einer dedizierten PostgreSQL-Datenbank, einem Verschlüsselungsschlüssel und den richtigen Host- und Webhook-URLs. Speichere dies als docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Führe dann docker compose up -d aus. Ein paar Dinge sind wichtig: Setze einen starken N8N_ENCRYPTION_KEY (er verschlüsselt deine gespeicherten Zugangsdaten, und ihn zu verlieren heißt, jede Zugangsdaten neu einzugeben), richte WEBHOOK_URL auf deine echte öffentliche HTTPS-Domain und setze Port 5678 nie ohne Reverse Proxy davor direkt dem Internet aus.

Die Teile, die Selbsthosting-Tutorials auslassen

n8n zum Laufen zu bringen ist die leichten 20%. Es sicher am Laufen zu halten sind die anderen 80%, und genau da beißt dich ein nackter VPS:

• TLS-Zertifikate: Du brauchst HTTPS für Webhooks und OAuth. Das heißt Caddy, Traefik oder Nginx plus Let’s Encrypt und eine Zertifikatserneuerung, die nicht scheitern darf.
• Webhooks und Reverse Proxy: Eingehende Webhooks brauchen eine stabile öffentliche URL und korrekte Proxy-Header, sonst brechen Trigger stillschweigend.
• Backups: Deine Workflows, Zugangsdaten und dein Ausführungsverlauf liegen in PostgreSQL. Du brauchst automatisierte, getestete Datenbank-Backups: Ein ungetestetes Backup ist kein Backup.
• Updates: n8n liefert häufig neue Versionen. Du bist verantwortlich dafür, neue Images zu ziehen, Hinweise zu Breaking Changes zu lesen und die Datenbank zu migrieren.
• Verfügbarkeit: Ein einzelner VPS ist ein Single Point of Failure. Wenn der Host um 2 Uhr nachts neu startet, stehen deine geplanten Workflows und Webhooks still, bis du es merkst.

Häufig gestellte Fragen