Wie viel RAM braucht selbst gehostetes n8n?

Rund 2 GB sind der bequeme Sweetspot für n8n plus seine Postgres-Datenbank und normale Workflows. Es läuft in 1 GB, wenn Workflows leicht sind, aber du wirst es bei größeren Läufen spüren. Schwere parallele Ausführungen oder große Payloads — geh auf 4 GB.

Brauche ich Docker, um n8n selbst zu hosten?

Es ist bei Weitem der einfachste Weg — eine Compose-Datei gibt dir n8n, eine Datenbank und persistenten Speicher, und Upgrades sind ein einzelner Pull. Du kannst stattdessen über npm installieren, aber Docker erspart dir die Abhängigkeits- und Upgrade-Kopfschmerzen.

Ist das Selbst-Hosten von n8n günstiger als n8n Cloud?

Wenn du einen stetigen Strom von Automatisierungen betreibst, ja — ein flacher monatlicher VPS schlägt Pro-Ausführungs-Preise, und es gibt kein Workflow- oder Ausführungslimit. Für eine Handvoll Läufe im Monat kann ein gehosteter Sitzplatz einfacher sein. Der andere Grund, aus dem Leute selbst hosten, ist Kontrolle: deine Daten und API-Schlüssel verlassen nie deinen Server.

Brauche ich eine Domain für n8n?

Für OAuth-basierte Nodes (Google usw.) und sauberes HTTPS ja — richte eine Domain auf den Server und stell n8n hinter einen Reverse-Proxy mit einem Zertifikat. Für rein interne Nutzung kannst du es über einen SSH-Tunnel ohne Domain erreichen.

Kann n8n auf einem NAT-VPS laufen oder brauche ich eine dedizierte IP?

Interne/SSH-Tunnel-Nutzung funktioniert auf einer NAT-Maschine. Wenn du eine öffentliche URL mit deiner eigenen Domain und HTTPS willst (nötig für manche OAuth-Callbacks und Webhooks), ist ein Plan mit dedizierter IP der sauberere Sitz, da du alle Ports kontrollierst.

n8n auf einem VPS mit Docker selbst hosten

n8n ist die Art Werkzeug, das du zunächst leicht nutzt und dann still die Hälfte deiner Abläufe hindurchleitest. Ab dem Punkt fühlt sich „es läuft auf jemandes Cloud-Sitzplatz, pro Ausführung gemessen, mit meinen API-Schlüsseln, die auf ihren Servern leben“ weniger großartig an. Selbst-Hosten behebt alle drei — flache Kosten, kein Ausführungslimit, und deine Schlüssel bleiben auf einer Maschine, die dir gehört. Mit Docker ist es ein Fünfzehn-Minuten-Job.

Wie viel Server es tatsächlich braucht

Zuerst ehrliche Zahlen, damit du nicht zu viel oder zu wenig kaufst:

~2 GB RAM ist der Sweetspot — n8n plus seine Postgres-Datenbank plus normale Workflows sitzen hier bequem.
1 GB funktioniert, wenn deine Workflows leicht sind, aber du wirst es bei größeren Läufen bemerken.
4 GB, wenn du schwere parallele Ausführungen machst oder große Payloads durchschiebst.

n8n ist im Ruhezustand nicht CPU-hungrig; es spitzt während Läufen. Eine 2-Kern-Maschine ist für die meisten Setups in Ordnung. (Mehr zum Abgleich von Specs und Workload im Dimensionierungs-Leitfaden.)

Das Docker-Setup

Auf einer frischen Ubuntu-/Debian-Maschine installiere Docker:

curl -fsSL https://get.docker.com | sudo sh

Erstelle einen Ordner und eine docker-compose.yml — n8n mit einem persistenten Volume und Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Zwei Dinge sind hervorzuheben: die Volumes (n8n-data, db-data) sind, was deine Workflows über Neustarts und Upgrades hinweg am Leben hält — überspring sie nicht. Und n8n ist an 127.0.0.1 gebunden, nicht 0.0.0.0 — es ist nicht direkt ins Internet offengelegt. Das ist absichtlich; der nächste Schritt handhabt den Zugriff sicher.

Zugriff: HTTPS oder ein Tunnel

Öffentliche URL (nötig für OAuth-Nodes und Webhooks): richte eine Subdomain auf den Server und betreibe einen Reverse-Proxy (Caddy ist am aufwandärmsten — automatisches HTTPS) vor 127.0.0.1:5678. Hier passt ein Plan mit dedizierter IP, da du Ports und DNS kontrollierst.
Nur für dich, keine Domain: überspring den Proxy und erreiche es über einen SSH-Tunnel — ssh -L 5678:127.0.0.1:5678 user@server, dann öffne localhost:5678. Funktioniert gut auf einem NAT-VPS.

Riegle es ab und halte es oben

n8n hält deine API-Schlüssel und Zugangsdaten, also muss die Maschine dicht sein: mach die Sicherheits-Checkliste (SSH-Schlüssel, Firewall, kein Passwort-Login), bevor du echte Zugangsdaten hineinlegst. restart: always in der Compose-Datei bedeutet bereits, dass Docker n8n nach einem Absturz oder Neustart zurückbringt — das ist deine Verfügbarkeit gehandhabt.

Lohnt es sich?

Sei ehrlich zu dir selbst über das Volumen. Wenn du ständig Automatisierungen betreibst, gewinnt Selbst-Hosten bei den Kosten (flach vs pro Ausführung) und entfernt jegliche Workflow-/Lauf-Limits. Wenn du ein paar Flows im Monat auslöst, ist ein gehosteter Sitzplatz weniger Aufwand. Aber das Kontroll-Argument steht unabhängig davon: deine Workflows, deine Daten, deine Schlüssel — auf deinem Server, nicht gemietet. Für die meisten, die es mit n8n ernst gemeint haben, ist das der entscheidende Faktor.

Eine 2-GB-Maschine, eine Compose-Datei, eine Domain (oder ein Tunnel), und du betreibst deinen eigenen Automatisierungs-Hub — zahlbar in Krypto ohne KYC, live in Minuten.

Fertiges Setup: siehe VPS für n8n — der empfohlene Plan und ein Krypto-Deploy in einer Minute.