Alle Produkte 
So wählen Sie einen VPS für n8n und richten ihn ohne Überraschungen ein
n8n ist ein Baukasten für Automatisierungen, den Sie statt eines Cloud-Abos auf Ihrem eigenen Server installieren können. Die eigene Installation hebt die Limits für Ausführungen und Workflows auf, und Daten sowie Zugangsdaten zu Diensten bleiben bei Ihnen. Der Preis dafür: ein virtueller Server und eine halbe Stunde Einrichtung.
Wie viele Ressourcen n8n braucht
n8n selbst ist eine Node.js-Anwendung und belegt im Leerlauf einige hundert Megabyte Arbeitsspeicher. Last erzeugen die Workflows: große API-Antworten, Dateien, Schleifen über Tausende Datensätze, Code-Nodes. Ungefähre Richtwerte:
- 1–2 GB RAM, 1 Kern – private Automatisierungen, Dutzende Ausführungen pro Stunde, SQLite-Datenbank.
- 2–4 GB RAM, 2 Kerne – produktive Team-Instanz mit PostgreSQL im benachbarten Container. Dieses Minimum ist auch im Filter dieser Seite eingestellt.
- 4–8 GB RAM und mehr – Queue-Modus mit Workern, Verarbeitung von PDFs und Bildern, lange KI-Ketten.
Aufrufe externer KI-Modelle über AI-Nodes verkraftet ein normaler Tarif. Soll das Modell dagegen direkt auf dem Server laufen, sind die Speicheranforderungen ganz andere – siehe VPS für KI-Modelle auf der CPU.
Docker, Postgres und Verschlüsselungsschlüssel
Am bequemsten installieren Sie n8n per Docker Compose: ein n8n-Container, ein PostgreSQL-Container und ein Reverse Proxy. Docker braucht eine vollwertige Virtualisierung, wählen Sie daher KVM; mehr zur Vorbereitung des Servers auf der Seite VPS für Docker.
Standardmäßig speichert n8n alles in SQLite. Zum Ausprobieren reicht das, doch mit wachsender Ausführungshistorie bläht sich die Datenbankdatei auf, und der Queue-Modus funktioniert mit SQLite nicht. PostgreSQL ist zuverlässiger und lässt sich per pg_dump leichter sichern.
Setzen Sie die Variable N8N_ENCRYPTION_KEY ausdrücklich und bewahren Sie eine Kopie außerhalb des Servers auf. Mit diesem Schlüssel sind alle gespeicherten Zugangsdaten verschlüsselt: Ohne ihn stellt ein Datenbank-Backup die Zugänge zu den Diensten nicht wieder her.
Webhooks und HTTPS
Viele Trigger – Bots, Zahlungssysteme, Formulare auf der Website – senden Ereignisse an einen Webhook, und fast alle verlangen HTTPS mit gültigem Zertifikat. Sie brauchen eine Domain oder Subdomain, die auf die IP des Servers zeigt, und einen Proxy wie Caddy oder nginx mit einem Let's-Encrypt-Zertifikat. Tragen Sie die öffentliche Adresse in WEBHOOK_URL ein, sonst zeigen die Nodes interne Links auf localhost:5678.
Öffnen Sie Port 5678 nicht nach außen. Docker veröffentlicht Ports an ufw vorbei, binden Sie den Container daher an 127.0.0.1 und lassen Sie den Editor nur über den Proxy erreichen.
Queue-Modus
Wenn ein einzelner Prozess nicht mehr hinterherkommt, stellt man n8n auf den Queue-Modus um: Die Hauptinstanz nimmt Webhooks entgegen und legt Aufträge in Redis ab, separate Worker führen sie aus. Nötig sind PostgreSQL, Redis und derselbe Verschlüsselungsschlüssel für alle Prozesse. Auf einem VDS mit 4–8 GB Arbeitsspeicher funktioniert dieses Setup problemlos; Worker auf eigene Maschinen auszulagern lohnt sich, wenn ihnen die Kerne ausgehen.
Wo der Server stehen sollte
Achten Sie darauf, womit Ihre Workflows arbeiten. Für internationale APIs ist ein Server in Europa oder den USA praktisch: Manche Dienste nehmen keine Anfragen von IPs aus bestimmten Ländern an. Für lokale CRMs, Banken und Marktplätze ist ein Server im selben Land naheliegend. Das Land stellen Sie in den Filtern ein, und die Zahlungswege jedes Tarifs sehen Sie in der Spalte „Zahlung“.