n8n selbst hosten: Die Free-Tier-Grenzen

n8n Cloud stoppt jeden Workflow in dem Moment, in dem Sie das monatliche Execution-Limit überschreiten – keine Warnung, keine Karenzzeit, keine Overage-Option, einfach Stille bis zum nächsten Abrechnungszyklus. Feuert ein einzelner Workflow bereits alle fünf Minuten, sind das rund 8.640 Executions im Monat – genug, um das 2.500-Execution-Limit des €24/Monat teuren Starter-Plans in etwa neun Tagen zu sprengen. Die naheliegende nächste Frage: Ist Self-Hosting tatsächlich ein Rückschritt, oder einfach nur ein anderes Set an Kompromissen?

TL;DR

Die n8n Community Edition (selbst gehostet) ist kostenlos, mit unbegrenzten Executions und dem vollständigen Integrations-Katalog – die Software selbst ist nicht der limitierende Faktor.
Was der Community Edition tatsächlich fehlt, sind reine Enterprise-Features: SSO/LDAP, Environments, externes Secret-Management, Log-Streaming und Git-basierte Versionskontrolle.
Rechnen Sie mit 300–500 MB RAM im Leerlauf, mit Spitzen von 1–2 GB bei intensiven Workflow-Läufen; 4 GB sind auf einer Homelab-Box der realistische Sockelbetrag, nicht das offizielle 2-GB-Minimum.
Schon ein einzelner Workflow, der alle 5 Minuten feuert, würde das Execution-Limit des Cloud-Starter-Plans in etwa 9 Tagen sprengen – Self-Hosting entfernt diese Obergrenze komplett.
Self-Hosting ist die falsche Wahl, wenn ein Team wirklich SSO, geteilte Environments oder Git-basierte Workflow-Versionierung braucht – dafür gibt es Enterprise Cloud.

Was Self-Hosting von n8n Ihnen wirklich bringt

Die selbst gehostete Community Edition läuft mit derselben zugrunde liegenden Software wie n8n Cloud, kostenlos, ohne Execution-Limit und mit Zugriff auf den kompletten Node-/Integrations-Katalog. Der Kompromiss liegt nicht bei der Software – sondern darin, dass Infrastruktur, Uptime, Backups und Updates zu Ihrer Verantwortung werden statt zu der von n8n.

Für alle, die bereits ein Homelab betreiben, ist diese Verantwortung kleiner, als es klingt. n8n ist einfach ein weiterer Container, der sich in dasselbe Layout einfügt, das schon für den Rest des Stacks verwendet wird: Proxmox erstellt die VM, Docker läuft darin, und n8n ist nur ein weiterer Dienst in dieser Docker-Compose-Datei statt ein Sonderfall mit eigenen Infrastruktur-Entscheidungen.

Was die Community Edition wirklich nicht bietet

Feature	Community (selbst gehostet)	Enterprise (Cloud oder selbst gehostet)
SSO / LDAP	Nein – nur lokale Accounts	Ja
Environments (Trennung Staging/Prod)	Nein	Ja
Externes Secret-Management	Nein	Ja
Log-Streaming	Nein	Ja
Git-basierte Versionskontrolle	Nein	Ja
Multi-Main-Modus (HA)	Nein	Ja
Executions	Unbegrenzt	Je nach Plan

Jede Zeile oben außer der letzten ist ein Feature, das vor allem auf Team- oder Organisationsebene zählt – Single-Sign-On, Environment-Trennung und Workflow-Versionierung lösen Koordinationsprobleme, die eine Solo-Homelab-Automatisierung gar nicht hat. Für eine einzelne Person, die ihre eigene Infrastruktur automatisiert, machen sich die Lücken der Community Edition kaum bemerkbar; für ein fünfköpfiges Team, das Workflows teilt, schon.

Praxis: Docker Compose auf einer Homelab-Box

Passend zur Praxis, Docker-Dienste in einer dedizierten VM statt direkt auf dem Proxmox-Host laufen zu lassen, kommen n8n und seine Datenbank als zwei Services dazu:

services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
    restart: unless-stopped

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  n8n_data:
  postgres_data:

Ein Reverse-Proxy mit TLS-Terminierung davor (Caddy oder Nginx) ist nicht optional – webhook-getriggerte Workflows, die den Großteil dessen ausmachen, was n8n nützlich macht, brauchen einen echten HTTPS-Endpunkt, um Callbacks von externen Diensten zu empfangen.

Was es wirklich an Ressourcen kostet

n8ns offizielles Minimum liegt bei 1 vCPU und 2 GB RAM – genug, um es mit SQLite im Testmodus zu starten, aber nicht viel mehr. In der Praxis pendelt der Container im Leerlauf bei 300–500 MB RAM und springt bei Workflow-Läufen mit größeren Payloads auf 1–2 GB – allein ein Code-Node, der eine 100-MB-Payload verarbeitet, kann kurzzeitig etwa 300 MB im Speicher halten. Auf der N100-Klasse Mini-PC-Hardware, die die Homelab-Guides dieser Seite bereits voraussetzen, sind 4 GB RAM der realistische Sockelbetrag, um n8n zuverlässig neben einer Handvoll anderer Container zu betreiben – nicht das nackte 2-GB-Minimum.

KEY-STAT: ~9 Tage — so lange dauert es, bis ein einzelner Workflow, der alle 5 Minuten pollt, das Execution-Limit des n8n-Cloud-Starter-Plans überschreitet

Ob dieser Container in eine VM oder einen LXC-Container gehört, ist dieselbe Frage, die bei jedem Docker-Workload auf Proxmox aufkommt – n8n hat hier keine Sonderanforderung, also gelten die allgemeinen Kompromisse zwischen VM und Container unverändert: Eine VM kostet etwas mehr RAM-Overhead, isoliert n8ns Kernel aber vollständig vom Host – das zählt mehr, sobald Webhook-Endpunkte über einen Reverse-Proxy dem Internet ausgesetzt sind.

Die Workflows, für die sich das lohnt

Drei Muster decken das meiste ab, wofür eine Homelab-n8n-Instanz am Ende genutzt wird:

Backup-Fehler-Alarme – ein geplanter Workflow pingt bei Erfolg einen Healthcheck-Endpunkt an; bleibt der Check-in planmäßig aus, löst ein separater Monitor eine Benachrichtigung aus. Billige Versicherung gegen einen Backup-Job, der schon vor Wochen unbemerkt aufgehört hat zu laufen.
RSS-zu-Benachrichtigung – ein RSS-Feed-Node überwacht neue Einträge und leitet sie an Discord, eine Chat-App oder E-Mail weiter und ersetzt so einen kostenpflichtigen „If This Then That"-Dienst durch ein selbst gehostetes Äquivalent.
Uptime-Checks – ein geplanter HTTP-Request-Node pingt selbst gehostete Dienste in festen Intervallen an und schlägt bei einer fehlgeschlagenen Antwort Alarm – eine leichtgewichtige Ergänzung zu einem dedizierten Monitoring-Stack, kein Ersatz dafür.

Keines davon braucht Enterprise-Features – es sind Single-User-, Single-Environment-Automatisierungen, genau die Art von Workload, für die die Community Edition gebaut ist.

Self-Hosted vs. Cloud: Die echte Kostenrechnung

Der Cloud-Starter-Plan kostet etwa €24/Monat für 2.500 Executions. Ein einzelner Workflow, der alle 5 Minuten pollt, erzeugt allein schon rund 8.640 Executions im Monat – genug, um dieses Limit in etwa 9 Tagen auszuschöpfen, noch bevor ein zweiter Workflow dazukommt. Self-Hosting entfernt die Execution-Obergrenze komplett; die einzigen laufenden Kosten sind Hardware und Strom, die ohnehin schon in eine Homelab-Box investiert wurden, auf der vermutlich sowieso weitere Dienste laufen.

Warning

Die Community Edition hat keine automatische HA oder Failover – geht die VM, auf der n8n läuft, offline, stoppen alle geplanten und webhook-getriggerten Workflows, bis sie wieder läuft. Für private Automatisierung ist das ein akzeptabler Kompromiss; für alles Geschäftskritische nicht.

Wann Self-Hosting die falsche Wahl ist

Braucht ein Team wirklich SSO, das an einen Unternehmens-Identity-Provider angebunden ist, getrennte Staging-/Produktions-Environments oder Git-basiertes Review von Workflow-Änderungen vor dem Go-live, ist Enterprise Cloud (oder selbst gehostetes Enterprise) das richtige Werkzeug – nicht eine selbst gehostete Community-Instanz, die über ihren Auslegungsbereich hinaus gedehnt wird. Für eine einzelne Person, die ihr eigenes Proxmox-Homelab automatisiert, ist das ein Featureset, das Probleme löst, die man noch gar nicht hat.

Tip

Starten Sie nur mit dem Workflow, der die meiste manuelle Kontrolle einsparen würde – ein Backup-Healthcheck oder ein Uptime-Ping – statt zu versuchen, jede Automatisierungsidee sofort in n8n zu migrieren.

Häufig gestellte Fragen

Ist selbst gehostetes n8n wirklich kostenlos?

Die Software ist unter der Community Edition kostenlos, mit unbegrenzten Workflow-Executions. Die einzigen echten Kosten sind der Server, auf dem sie läuft – bei einer Homelab-Box, auf der bereits andere Dienste laufen, ist das meist nur ein marginaler Anteil an geteiltem RAM und Strom, keine neue Ausgabe.

Brauche ich eine Domain und SSL, um n8n selbst zu hosten?

Für webhook-getriggerte Workflows ja – externe Dienste brauchen einen echten HTTPS-Endpunkt für ihre Callbacks. Ein Reverse-Proxy wie Caddy oder Nginx mit TLS-Terminierung vor n8n, wie im Compose-Beispiel oben gezeigt, ist das Standard-Setup.

Kann selbst gehostetes n8n dieselben Integrationen wie Cloud nutzen?

Ja. Die Community Edition wird mit demselben Node- und Integrations-Katalog wie Cloud ausgeliefert. Was fehlt, sind Account-/Team-Management-Features (SSO, Environments, externe Secrets), keine Integrationen.

Welche Features hat die n8n Community Edition nicht?

SSO-/LDAP-Authentifizierung, Environments (Trennung Staging/Produktion), externes Secret-Management, Log-Streaming, Multi-Main-High-Availability-Modus und Git-basierte Versionskontrolle sind laut n8ns eigener Dokumentation alle reine Enterprise-Features.