Was du brauchst
Die Größe ist laut Doku ein Startwert, kein gemessenes Minimum. Mehrere Browser-Aufgaben gleichzeitig oder lokale Modelle brauchen mehr. Als Anbieter für einen gemieteten Server nennt die Doku Hetzner Cloud und DigitalOcean, jeweils mit Ubuntu 24.04. Bei Hetzner zahlst du laut Doku auch für einen ausgeschalteten Server, solange er angelegt ist. Kleine Gratis-Maschinen haben weniger Arbeitsspeicher als der Startwert. Welche Hardware für lokale Modelle taugt und was sie kostet, habe ich in Eigener KI-Server: Hardware und Kosten zusammengetragen.
Fertiges Paket oder Quellcode
Die Doku beschreibt zwei Wege. Fertige Server-Pakete mit Installer liegen in den „private Nod releases“; laden kannst du sie nur mit Zugriff auf das Repository. Die Pakete aus den automatischen Builds verfallen laut Doku nach 14 Tagen. Der Vorteil eines Pakets: Der Server muss nichts kompilieren.
Öffentlich bleibt der Weg aus dem Quellcode. Dabei baut der Server die Anwendung und die Browser-Werkzeuge selbst. Eine eigene Datenbank brauchst du bei keinem der beiden Wege, PostgreSQL läuft im Stack mit. Ich habe den Quellcode-Weg genommen, und den beschreibe ich hier.
Schritt für Schritt: Nod aus dem Quellcode bauen
1. Code holen
git clone --depth 1 --branch nod-v0.7.6 https://github.com/n8n-io/nod.git
cd nod/deployment/self-host
Die Doku klont ohne --branch. Ich habe eine feste Version genommen, weil die Doku für Updates rät, ein Release oder einen Commit festzuhalten, damit du weißt, was auf dem Server läuft. Die aktuelle Version steht in den Releases auf GitHub.
2. Konfiguration erzeugen
sh setup.sh
Das Skript legt eine private Datei .env an mit dem Server-Token, dem Vault-Schlüssel für gespeicherte Zugänge und dem Datenbank-Passwort. Laut Doku gibt es die Geheimnisse nie aus und lässt eine vorhandene .env in Ruhe. In meinem Lauf hatte die Datei die Rechte 600, und das Skript prüfte vorher, ob Docker Engine 25 oder neuer und OpenSSL da sind. Lass diese Datei auf dem Server und zeig sie nie auf dem Bildschirm, etwa bei einer Aufnahme.
3. Bauen und starten
docker compose up -d --build --wait
Ich habe den Befehl mit --file compose.yaml --env-file .env ausgeführt, das sind die Dateien, die er ohnehin nimmt. Der erste Build lief bei mir von 12:57 bis 13:09 Uhr, also rund 12,5 Minuten. Die meiste Zeit ging in Downloads: das Rust-Image, Debian-Pakete samt LibreOffice und npm-Pakete, einige davon mit weniger als 50 KiB/s. Lass das Terminal offen, bis der Befehl fertig ist. Spätere Starts nutzen die fertigen Images.
Danach meldeten sechs Container den Status „healthy“. Die drei großen Images:
4. Im Browser öffnen
Auf demselben Rechner öffnest du http://localhost:4310. Steht der Server woanders, öffnest du vorher einen SSH-Tunnel (unten). Der Port war in meinem Test nur an 127.0.0.1 gebunden; die Compose-Datei nimmt 127.0.0.1, solange du NOD_BIND_ADDRESS nicht änderst. Ein Aufruf ohne Token bekam die Antwort HTTP 403.
Ins Zugangsformular gehört der Wert von NOD_AUTH_TOKEN aus der .env. Statt die Datei zu öffnen, kopierst du ihn auf dem Mac direkt in die Zwischenablage, ohne dass er auf dem Bildschirm erscheint:
grep '^NOD_AUTH_TOKEN=' .env | cut -d= -f2- | tr -d '\n' | pbcopy
Liegt der Server woanders, holst du das Token per SSH direkt in die Zwischenablage deines Macs, ohne dass es auf einem Bildschirm erscheint:
ssh <user>@<server-adresse> "grep '^NOD_AUTH_TOKEN=' nod/deployment/self-host/.env | cut -d= -f2-" | tr -d '\n' | pbcopy
Den Pfad passt du an den Ordner an, in den du Nod geklont hast.
5. Einrichtung abschließen
Danach folgt dieselbe Einrichtung wie in der App: optional E-Mail, ein paar Fragen über dich, ein Modell, die Entscheidung über Gesprächsverläufe. Zur Installation brauchst du laut Doku keinen Modell-Schlüssel, ohne Modell arbeitet Nod aber nicht.
Was auf dem Server läuft
Mit HTTPS kommt ein siebter Container dazu, Caddy als Reverse Proxy. Datenbank, Workspace und Browser bleiben laut Doku privat, Modell-Schlüssel und gespeicherte Zugänge bleiben beim Server, außerhalb von Workspace und Browser. Die Daten liegen in benannten Docker-Volumes. Einen Container neu anzulegen lässt sie stehen, die Volumes zu löschen löscht deine Daten.
Zugang von außen
SSH-Tunnel ohne Domain
Der einfachste Weg auf einen entfernten Server führt über SSH. Auf deinem eigenen Rechner:
ssh -L 4310:127.0.0.1:4310 <user>@<server-adresse>
Lass die Verbindung offen und öffne http://localhost:4310. NOD_PUBLIC_URL bleibt dafür auf dem Standard, das Token brauchst du trotzdem. Willst du einen anderen Port, änderst du PORT in der .env und nimmst ihn auch im Tunnel und im Browser.
HTTPS mit Domain und Caddy
Richte eine Domain wie nod.example.com auf die öffentliche Adresse deines Servers und erlaube eingehend TCP 80 und 443.
Trag in der .env ein: NOD_PUBLIC_URL=https://nod.example.com
Starte mit dem HTTPS-Profil:
docker compose --profile https up -d --build --wait
Öffne die HTTPS-Adresse und gib das Token ein.
Caddy holt und erneuert das Zertifikat. Nutz --profile https laut Doku dann bei jedem Start, Stopp und Statusbefehl. Klappt das Zertifikat nicht, prüfe DNS und ob Anbieter oder Router die Ports 80 oder 443 sperren. Hast du schon einen eigenen Reverse Proxy, leitest du auf den Port 4310 weiter, behältst den Host-Header, unterstützt WebSockets und Streaming und setzt NOD_PUBLIC_URL auf genau diese HTTPS-Adresse.
Desktop-App mit dem Server verbinden
Beim ersten Start der App wählst du Connect to a server, später über Replay onboarding… im Nod-Menü. Dann trägst du die Server-Adresse und das Token ein: die HTTPS-Adresse oder http://localhost:4310, solange dein SSH-Tunnel offen ist. Die App prüft den Server, bevor sie das Token im sicheren Speicher deines Betriebssystems ablegt.
Danach nutzt die App Gespräche, Dateien, Modelle und Konten des Servers. Schließt du sie, läuft der Server weiter. Der lokale Assistent der App bleibt getrennt; laut Doku wandern dabei keine Daten mit. Für die Anmeldung mit ChatGPT auf einem entfernten Server kopierst du am Ende die Adresse aus dem Browser in Callback URL; den Port 1455 musst du laut Doku nicht öffnen.
Apps auf dem Server verbinden
Unter Apps wählst du Connect. Für Apps über Composio öffnet Nod eine Anmeldeseite unter deiner NOD_PUBLIC_URL. Wähle Continue to sign in, schließ die Anmeldung im neuen Fenster ab und lass die erste Seite offen, bis die Verbindung steht. Blockt dein Browser Popups, erlaube sie für Nod. Der SSH-Tunnel oder HTTPS-Proxy, über den du Nod öffnest, trägt auch diese Anmeldung, einen weiteren Port brauchst du laut Doku nicht. Nach einem Neustart des Servers oder einer neuen Adresse startest du die Verbindung neu.
Telegram und WhatsApp
Unter Channels verbindest du Telegram oder WhatsApp, beide teilen sich den Assistenten des Servers. Für den Server gilt laut Doku:
- Telegram mit Abfrage und WhatsApp per QR-Code bauen die Verbindung von innen nach außen auf. Sie funktionieren ohne Domain und ohne offenen Port am Router.
- Telegram-Webhooks und die WhatsApp Cloud API von Meta brauchen eine öffentliche HTTPS-Adresse.
- Für Telegram legst du mit BotFather einen Bot an. Danach darf nur das Telegram-Konto schreiben, das du verknüpfst.
- Die WhatsApp-Verbindung per QR-Code nutzt laut Doku Baileys, einen inoffiziellen WhatsApp-Client. n8n nennt ein kleines Risiko von Kontosperren und rät zu einer eigenen Bot-Nummer.
- Anmeldungen und Zahlungen bleiben in der Web- oder Desktop-App, sie laufen nie über den Chat.
Auf dem Server bleiben die Kanäle verbunden, solange er läuft.
Sicherheit: was du wissen musst
Ein Server, eine Person. Laut Doku gibt es keine Registrierung und keine Mehrbenutzer-Einrichtung. Das Token gibt vollen Zugriff auf den Assistenten und alle verbundenen Konten. Behandle es wie ein Passwort zu deinem Postfach. Musst du es tauschen, erzeugst du auf dem Server ein neues mit openssl rand -hex 32, ersetzt NOD_AUTH_TOKEN in der .env und startest den Server mit docker compose up -d --wait server neu. Der Befehl zeigt das neue Token im Terminal; führ ihn nie bei einer Aufnahme oder bei geteiltem Bildschirm aus. Den NOD_VAULT_KEY tauschst du dafür nie, sonst lassen sich gespeicherte Zugänge nicht mehr lesen.
Docker-Socket im Hilfscontainer. Damit der Server Workspace und Browser steuern kann, bekommt der Container runtime den Docker-Socket des Hosts (/var/run/docker.sock). Wer diesen Socket bedienen kann, hat praktisch Root-Rechte auf dem Host. Nod reicht ihn deshalb nur an den Hilfscontainer weiter, der dem Server laut Doku eine eingeschränkte Docker-Verbindung bereitstellt. Die Compose-Datei von Version 0.7.6 hält den Hilfscontainer deshalb klein: nur lesendes Dateisystem, alle Linux-Capabilities entzogen, 128 MB Arbeitsspeicher. Der Workspace selbst bekommt laut Doku keinen Socket. Die Doku sagt dazu klar: PostgreSQL, Browser, Workspace und die Docker-Verbindung nie nach außen öffnen.
NET_ADMIN für die Firewall des Workspace. Der Container workspace-network bekommt als einziges Recht NET_ADMIN. Er sperrt laut Doku private und reservierte IPv4-Ziele und externes IPv6, und der Workspace startet erst, wenn diese Firewall steht. Seine DNS-Anfragen gehen an 1.1.1.1 und 8.8.8.8. Wenn du die Compose-Datei änderst, lass diesen Dienst und seine Netzwerkeinstellungen drin.
Metadaten-Dienst bei Cloud-Servern. Bei Cloud-VMs können Metadaten-Dienste Zugangsdaten der Cloud an Befehle im Workspace geben. Die Firewall des Workspace sperrt laut Doku auch die Metadaten-Dienste der Cloud. Lass sie deshalb an und sperr den Zugriff zusätzlich beim Anbieter, bei AWS etwa über die Instance Metadata Options.
Firewall des Anbieters nutzen. Docker kann laut Doku mit veröffentlichten Ports Regeln von ufw umgehen. Nimm deshalb auch die Firewall deines Anbieters, öffne nur 80 und 443 für den Proxy und beschränke SSH auf deine Adresse. Auch im privaten Netz oder über VPN bleibt die Anmeldung per Token an. Wie du einen Server grundsätzlich härtest, mit Schlüsseln statt Passwörtern, Updates und Netzwerkfilter, steht in Eigenen Server absichern: Linux und Windows. Welche Daten trotz eigener Hardware an Modell, n8n und weitere Dienste gehen, steht in Nod Datenschutz: was der KI-Agent weitergibt.
Dauerbetrieb, Backup und Updates
Die Container starten neu, wenn Docker startet. Diese Befehle führst du im Ordner nod/deployment/self-host aus, mit HTTPS jeweils mit --profile https:
Nie docker compose down --volumes, außer du willst die Daten wirklich löschen.
Backup. Warte, bis laufende Arbeit fertig ist, und gib ein neues Zielverzeichnis an, dessen übergeordneter Ordner existiert:
sh backup.sh /absoluter/pfad/nod-backup-2026-11-15
Das Skript stoppt Server, Browser und Workspace für die Kopie und startet danach wieder, was vorher lief. Im Backup stehen laut Doku die .env mit Token, Vault-Schlüssel und Datenbank-Passwort, ein Abzug der Datenbank, die Daten von Server, Workspace und Browser und der Commit, aus dem du gebaut hast. Das Backup enthält also Geheimnisse: verschlüsselt ablegen, Zugriff beschränken und eine Kopie weg vom Server halten. TLS-Zertifikate sind nicht dabei, Caddy holt neue.
Wiederherstellen geht laut Doku nur in eine frische Installation: Nod in einen neuen Ordner klonen, den Commit aus dem Backup auschecken, im Ordner deployment/self-host sh restore.sh /absoluter/pfad/nod-backup-2026-11-15 nod-restored ausführen, ohne vorher setup.sh. Den alten Server stoppst du vor dem Start des neuen, sonst laufen Zeitpläne doppelt. Ein Restore setzt die Daten auf den Stand des Backups zurück, Nachrichten und Aktionen danach macht er nicht ungeschehen.
Update aus dem Quellcode. Release-Hinweise lesen, Backup machen, dann:
docker compose stop
git fetch origin --tags
git checkout <release-tag-oder-commit>
docker compose up -d --build --wait
Datenbank-Migrationen laufen beim Start. Eine ältere Version darf laut Doku nicht auf eine schon aktualisierte Datenbank zeigen. Zurück geht es nur über das Backup vor dem Update.
Nod auf dem Mac mini
Ein Mac mini ist für Nod laut Doku einfach ein weiterer Server: Die Linux-Container laufen in der virtuellen Maschine von Docker Desktop, auf Apple Silicon als ARM64, auf Intel als AMD64. Es ist derselbe Stack wie auf einem Linux-Server. Die Desktop-App mit ihrem lokalen Assistenten brauchst du auf dem Mac mini nicht. Mein Test lief auf einem MacBook mit Docker Desktop, nicht auf einem Mac mini; nach der Doku ist der Aufbau derselbe.
So bereitest du den Mac vor:
- Installiere Docker Desktop für deinen Prozessor, Apple Silicon oder Intel.
- Gib Docker zum Start 8 GB Arbeitsspeicher und plane 50 GB freien Platz ein, mit Reserve für macOS.
- Schalte in Docker Desktop „Start Docker Desktop when you sign in to your computer“ ein. Docker startet damit nach der Anmeldung, nicht vorher.
- Lass den Mac wach, solange Nod laufen soll. Nach einem Stromausfall oder Neustart meldest du dich an und prüfst, ob Docker und Nod laufen. Laut Doku meldet sich ein Mac mit eingeschaltetem FileVault nie automatisch an.
- Installiere Nod wie oben, in einem eigenen Ordner nur für diese Installation.
Zugriff von unterwegs. Für öffentlichen Zugriff nimmst du Domain und HTTPS, dein Router muss dann die Ports 80 und 443 an den Mac weiterleiten. Manche Internetanschlüsse zu Hause sperren eingehende Verbindungen oder teilen sich eine öffentliche Adresse mit anderen Kunden (Carrier-Grade NAT), dann klappt das nicht. Für privaten Zugriff öffnest du einen SSH-Tunnel zum Mac, direkt oder über dein VPN. Ein VPN allein reicht laut Doku nicht: Es öffnet weder den Port, der nur an 127.0.0.1 hängt, noch liefert es das HTTPS, das Nod für eine entfernte Adresse verlangt. Telegram und WhatsApp per QR-Code laufen auch ohne geöffneten Router.
Daten. Desktop-App und Server-Stack haben getrennte Daten. Vor einem Update oder einer Neuinstallation von macOS machst du ein Backup mit backup.sh. Nur den Repository-Ordner zu kopieren sichert deinen Assistenten laut Doku nicht. Willst du auf demselben Mac mini auch lokale Modelle laufen lassen, findest du die passende Speichergröße in Lokale KI auf dem Mac.
Häufige Fragen
Brauche ich für Nod einen Mac mini?
Nein. Laut Doku läuft derselbe Stack auf jedem Linux-Server mit Docker, AMD64 oder ARM64, und auf jedem Mac mit Docker Desktop. Der Mac mini ist eine Möglichkeit, Nod auf eigener Hardware im eigenen Haus laufen zu lassen.
Wie viel Speicher braucht Nod auf dem Server?
Die Doku nennt als Startwert zwei CPU-Kerne, 8 GB Arbeitsspeicher und 50 GB Platte, ausdrücklich kein gemessenes Minimum. In meinem Test belegten allein die drei großen Images zusammen rund 4,9 GB, und während des Builds sank der freie Platz zeitweise um rund 9 GB.
Kann ich Nod ohne Domain von unterwegs nutzen?
Ja, über einen SSH-Tunnel zum Server. Für Telegram und WhatsApp per QR-Code brauchst du weder Domain noch offenen Port. Eine Domain mit HTTPS brauchst du erst, wenn du Nod ohne Tunnel im Browser öffnen willst oder Webhooks nutzt.
Kann mein Team sich einen Nod-Server teilen?
Laut Doku nicht. Ein Server gehört einer Person, das Token gibt vollen Zugriff auf alle verbundenen Konten. „Nod for your team“ steht bei n8n auf der Liste für später. Bis dahin braucht jede Person eine eigene Installation; auf einem Rechner geht das laut Doku mit eigenem Ordner und eigenem Port je Installation.
Läuft Nod weiter, wenn ich den Laptop zuklappe?
Mit einem eigenen Server ja: Zeitpläne, Telegram und WhatsApp laufen weiter, solange der Server läuft. Mit der Desktop-App auf dem Laptop nicht.
Kann ich die Desktop-App weiter nutzen?
Ja, als Fenster auf den Server über Connect to a server. Der lokale Assistent der App bleibt davon getrennt, Gespräche und Konten werden nicht übertragen.
Wie du weitermachst
Bau den Server zuerst dort, wo du ihn ohnehin vor dir hast, und greif per SSH-Tunnel darauf zu. Domain, HTTPS und offene Ports kommen erst dazu, wenn du sie wirklich brauchst. Bevor Nod an echte Konten darf, richtest du das Backup ein und prüfst es einmal mit einer Wiederherstellung. Härte den Server wie jeden anderen, wie in Eigenen Server absichern: Linux und Windows beschrieben. Wie ein eigener Server mit Claude Code und Slack für mehrere KI-Mitarbeiter aufgebaut ist, mit eigener Sitzung und eigenem Bot je Rolle, zeige ich in Claude Code auf dem Server betreiben; das ist mein Aufbau und ein ganz anderer Ansatz als Nod. Wie beide Wege bei Kosten, Abrechnung und Betrieb abschneiden, vergleiche ich in Nod vs Claude Code: KI-Agenten im Vergleich. In meiner deutschsprachigen Community Claude Practitioners zeige ich, wie ich KI-Mitarbeiter mit klaren Rechten und Freigaben aufbaue.
