n8n selbst auf einem VPS hosten.
Ihre Automatisierungs-Engine, Ihre Credentials, Ihr Metall.

n8n ist eine Workflow-Automatisierungs-Engine: eine visuelle Canvas, auf der Sie einen Trigger — einen Webhook, einen Zeitplan, eine neue Zeile in einer Datenbank, eine Nachricht in einer Queue — mit einer Kette von Nodes verdrahten, die APIs aufrufen, Daten transformieren, anhand von Bedingungen verzweigen, beliebiges JavaScript oder Python ausführen und das Ergebnis an das Nächste weiterreichen. Mehrere Hundert Integrations-Nodes sind bereits eingebaut, dazu ein generischer HTTP-Request-Node, der alles andere abdeckt. Seit der 1.x-Reihe bringt es außerdem AI-Agent- und LLM-Nodes mit, weshalb ein großer Teil der Leute, die es 2026 installieren, Agenten bauen statt klassischer ETL-Verrohrung.

Der Teil, der wichtig ist, bevor Sie auch nur einen Befehl eintippen, ist die Lizenz, denn n8n ist nicht Open Source im Sinne der OSI, und der Unterschied ist nicht akademisch. Der Kern wird unter der Sustainable Use License ausgeliefert: eine nicht-exklusive, lizenzgebührenfreie, weltweite Gewährung, die Software für interne Geschäftszwecke und für persönliche oder nicht-kommerzielle Nutzung zu verwenden, zu kopieren, zu verändern und weiterzugeben. Was sie vorenthält, ist das Recht, anderen n8n oder ein Derivat davon in Rechnung zu stellen — das ist die Klausel, die den Aufbau eines kostenpflichtigen „Managed n8n"-Produkts darauf ausschließt. Getrennt davon ist jede Datei, die .ee. im Namen oder .ee im Pfad trägt, vollständig aus dieser Lizenz ausgenommen und erfordert eine kostenpflichtige n8n Enterprise License.

Klar gesagt: n8n auf einem VPS zu betreiben, um die eigene Firma zu automatisieren, die Arbeit für die eigenen Kunden, die man als Dienstleistung erbringt, oder das eigene Privatleben, liegt innerhalb der kostenlosen Gewährung und lag es schon immer. n8n-als-Hosting-Produkt zu verkaufen, nicht. Fast jede „Ist n8n wirklich kostenlos?"-Diskussion im Internet besteht aus zwei Leuten, die genau über diese Grenze hinweg aneinander vorbeireden.

Die Kostenseite. n8n Cloud wird pro Ausführung abgerechnet: Der Starter-Plan kostet €20 im Monat, jährlich abgerechnet, für 2 500 Ausführungen, Pro kostet €50 im Monat für 10 000, Business kostet €667 im Monat für 40 000. Selbst gehostet ist die Anzahl der Ausführungen überhaupt kein Rechnungsposten — sie ist nur durch die CPU- und Speicherkapazität der Box begrenzt. Ein Workflow, der alle fünf Minuten eine API pollt, verbraucht allein schon 8 640 Ausführungen im Monat; auf Cloud zwingt dieser eine Workflow bereits die Pro-Stufe, und auf einem $3.90-VPS ist er ein Rundungsfehler gegenüber der Leerlauf-CPU.

Cloud-Preise wie auf n8n.io im August 2026 veröffentlicht, jährlich abgerechnet; monatliche Abrechnung kostet mehr. Der Tausch ist nicht nur eine Frage des Geldes — Self-Hosting verlagert Upgrades, Backups, TLS-Erneuerung und Uptime auf Ihre Seite der Grenze.

Im Panel: Order → VPS → Sentinel, Image Debian 12. Für die Kontoeröffnung ist keine E-Mail-Adresse erforderlich, an keiner Stelle wird ein Ausweisdokument verlangt, und die Rechnung wird in Monero, Bitcoin, Lightning oder einem der anderen unterstützten Assets beglichen. Wählen Sie den Bastion nach der Latenz zu den Diensten, die Sie automatisieren, statt zu sich selbst — ein Automatisierungsserver spricht weit mehr mit APIs als mit Ihnen.

Legen Sie dann den DNS-Eintrag an, bevor Sie den Server anfassen: einen A-Eintrag für n8n.example.com, der auf die VPS-IPv4 zeigt, und einen AAAA-Eintrag, falls Sie IPv6 nutzen. Das muss zuerst geschehen, weil Caddy in dem Moment, in dem der Stack startet, bei Let's Encrypt ein Zertifikat anfordert, und eine Zertifikatsanfrage für einen Namen, der nicht auflöst, schlägt fehl — zieht sich dann zurück, und Sie verbringen zwanzig Minuten damit, sich zu fragen, warum die Seite nicht erreichbar ist.

Geben Sie dem DNS eine Minute zum Propagieren und bestätigen Sie es von Ihrer eigenen Maschine aus, bevor Sie fortfahren:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

Bevor irgendetwas auf einem öffentlichen Port lauscht, arbeiten Sie die Härtungs-Checkliste für die erste Stunde ab — SSH nur mit Key, eine Firewall, die ausschließlich 22, 80 und 443 zulässt, und unbeaufsichtigte Sicherheitsupdates. Ein Automatisierungsserver ist ein Credential-Tresor; er verdient die volle Stunde.

Legen Sie zuerst das Verzeichnis an und generieren Sie die beiden Secrets. Generieren Sie sie jetzt, in dieser Reihenfolge, und fügen Sie sie dabei in die .env ein — insbesondere der Verschlüsselungsschlüssel muss vor dem ersten Boot von n8n existieren, nicht danach.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

Sperren Sie die Datei sofort ab — sie enthält den Schlüssel zu jedem Credential, das die Instanz jemals speichern wird:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

Zwei Designentscheidungen, die es wert sind, benannt zu werden. Erstens veröffentlicht n8n keinen Port. Nur Caddy bindet 80 und 443; n8n lauscht auf 5678 innerhalb des Compose-Netzwerks, wo nichts außerhalb des Hosts es erreichen kann. Eine überraschende Zahl selbst gehosteter n8n-Instanzen hängt ohne vorgeschaltetes TLS öffentlich am Port 5678 im Internet, und Suchmaschinen für exponierte Dienste indexieren sie. Zweitens bleibt das n8n-Datenvolume gemountet, obwohl PostgreSQL die Workflows jetzt hält — dieses Verzeichnis trägt weiterhin die Instanzeinstellungen, die Log-Dateien und die Source-Control-Assets.

Starten Sie den Stack:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

Ein n8n, das bootet, den Editor anzeigt und einen manuellen Test ausführt, ist noch kein funktionierendes n8n. Die Hälfte, die still und leise kaputtgeht, sind eingehende Webhooks, und zwar auf eine Weise, die so aussieht, als läge der Fehler beim Drittanbieter-Dienst.

WEBHOOK_URL. Ohne sie baut n8n Webhook-URLs aus N8N_HOST und N8N_PORT und liefert Ihnen etwas wie http://localhost:5678/webhook/abc — das Sie dann in Stripe oder GitHub einfügen, wo es niemals erreicht werden kann. Die Compose-Datei oben setzt WEBHOOK_URL auf die öffentliche HTTPS-Root, die der Editor anzeigen wird und die die Außenwelt tatsächlich aufrufen kann.

N8N_EDITOR_BASE_URL. Die öffentliche URL, die n8n für Links in den E-Mails verwendet, die es versendet — Passwort-Resets, Nutzereinladungen. Ist sie hier falsch, zeigt ein Einladungslink auf localhost, was eher ein Support-Ticket von einem Kollegen nach sich zieht als eine kaputte Integration.

N8N_PROXY_HOPS. n8n liest die Client-IP aus X-Forwarded-For und vertraut dabei nur so vielen Hops, wie diese Zahl angibt. Mit einem Reverse-Proxy davor — dem Caddy in diesem Stack — ist der Wert 1. Stellen Sie Cloudflare vor Caddy, wird er zu 2. Belassen Sie ihn beim Standardwert 0, scheint jede Anfrage vom Proxy selbst zu kommen, was Rate-Limits und jede IP-basierte Logik in Ihren Workflows still und leise zerstört.

N8N_SECURE_COOKIE. Es ist standardmäßig true, was bedeutet, dass das Session-Cookie nur über HTTPS gesendet wird. Das ist die richtige Einstellung, und dieser Stack erfüllt sie. Das lohnt sich zu wissen, weil es das klassische Symptom eines ersten Versuchs über einfaches http erklärt: Das Login-Formular akzeptiert das Passwort und schickt Sie dann wieder zurück zum Login-Formular, endlos. Die Lösung ist TLS, nicht das Abschalten des Flags.

Testen Sie es richtig. Erstellen Sie einen Workflow mit einem Webhook-Node, aktivieren Sie den Workflow, kopieren Sie die Production-URL, und rufen Sie sie dann von einer Maschine auf, die nicht der Server ist:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

Die Unterscheidung, über die jeder einmal stolpert: Die Test-URL lauscht nur, solange Sie den Editor geöffnet und „Listen for test event" scharf geschaltet haben. Die Production-URL existiert nur, wenn der Workflow auf Active geschaltet ist. Ein Webhook, der im Editor funktioniert und in Production ein 404 liefert, ist so gut wie immer ein inaktiver Workflow.

Standardmäßig läuft n8n im Regular Mode: Derselbe Prozess, der den Editor bereitstellt und Webhooks empfängt, führt auch die Workflows aus. Das ist einfach und funktioniert korrekt — bis ein langer Workflow die anderen warten lässt. Das Symptom ist unverkennbar: Ausführungen bleiben minutenlang auf „running" stehen, der Editor wird träge, und ein Webhook, der in 200 ms antworten sollte, antwortet erst nach acht Sekunden.

Queue Mode teilt die Arbeit auf. Die Hauptinstanz behält den Editor, die Trigger und die Webhook-Endpunkte; sie schiebt Execution-IDs in Redis; separate Worker-Prozesse holen sie ab, laden den Workflow aus PostgreSQL, führen ihn aus und melden über Redis zurück. Aus dieser Architektur folgen drei Regeln, und alle drei beißen jeden, der sie überspringt: Jede Instanz muss dieselbe PostgreSQL-Datenbank teilen, jede Instanz muss denselben N8N_ENCRYPTION_KEY tragen, und SQLite wird überhaupt nicht unterstützt.

Die Ergänzungen zur Compose-Datei sind ein Redis-Dienst und ein Worker-Dienst, der dasselbe n8n-Image ist, nur mit dem worker-Befehl ausgeführt:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

Fügen Sie EXECUTIONS_MODE=queue und QUEUE_BULL_REDIS_HOST=redis auch beim Haupt-n8n-Dienst hinzu — beide Seiten müssen sich über den Modus einig sein. Zwei Optionen lohnt es sich, gleich am ersten Tag zu setzen: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, damit ein Klick auf „Test workflow" im Editor den Hauptprozess nicht blockiert, und N8N_GRACEFUL_SHUTDOWN_TIMEOUT, das standardmäßig 30 Sekunden beträgt und bestimmt, wie lange ein Worker bei einem Redeploy Zeit hat, seinen aktuellen Job zu beenden. Wenn Ihre Workflows routinemäßig länger als eine halbe Minute laufen, erhöhen Sie den Wert, sonst tötet jedes Deployment laufende Arbeit ab.

Fangen Sie nicht hier an. Queue Mode fügt zwei bewegliche Teile und eine Fehlerklasse hinzu, die es im Regular Mode schlicht nicht gibt. Bleiben Sie im Regular Mode, bis Sie sehen, dass die Queue wächst oder ein Workflow einen anderen blockiert, und fügen Sie dann einen einzelnen Worker auf derselben Box hinzu, bevor Sie eine zweite Box hinzufügen. Diese Abstufung — Sentinel im Regular Mode, Garrison mit einem Worker, Ravelin mit dreien — deckt alles ab, was kurz vor einem wirklich großen Deployment liegt.