Zum Inhalt springen
senn-techsenn-tech
Zurück zum Blog
KI & Entwicklung
KI im Betrieb2026-11-11· Von Franz Senn

Nod von n8n Labs im Eigenbetrieb: Was die Agent-App wirklich braucht

Ende Oktober arbeitete auf meinem Rechner eine Agent-App, die es offiziell noch nicht gab. Mein Screenshot vom 27.10.2026 zeigt ihren Chat: dunkle Oberfläche, drei Aufgabenkarten für diesen Tag, darunter der Hinweis, ich könne Nod auch über Telegram oder WhatsApp verbinden. In der Statuszeile steht „Keep Nod running, so I can reply", während der Laptop klappt ist und der Rechner zu Hause weiterarbeitet. Am 10.11.2026 hat n8n Labs die App öffentlich angekündigt; das erste gelistete Release v0.6.1 trägt dasselbe Datum, v0.6.2 folgte am 11.11.2026. Mein Start lag also vor der Veröffentlichung, in der Phase davor. Ich schreibe das so genau, weil fast jede Zahl dieses Posts aus der Doku, dem Lizenztext und den Release-Paketen stammt, die ich zwischen dem 10. und 11.11.2026 selbst abgerufen habe.

Nod ist die Agent-App von n8n Labs für macOS 14 und Windows 11. Sie läuft auf dem eigenen Rechner in einer privaten virtuellen Maschine mit eigenem Browser und arbeitet dort an Dateien, Befehlen und Webseiten. Der Modellanbieter ist frei gewählt: Cloud-API oder ein eigener OpenAI-kompatibler Server. Die App steht unter Apache 2.0, kostet selbst nichts; die Modellkosten rechnet der jeweilige Anbieter ab.

Einzelplatz gegen geteilten Workflow

Die Abgrenzung zum bekannten n8n-Server zieht n8n selbst in einem Satz, wörtlich: „A lot of what people build in n8n is multiplayer … Nod is for a single player." Der Automation-Server, seit Jahren in vielen Betrieben selbst gehostet, ist ein Team-Werkzeug: geteilte Workflows, Rollen, Zugriffe, Freigaben. Nod dagegen ist ein Programm für eine Person, mit eigenem Arbeitszimmer aus Dateien, Shell und Browser auf genau einem Rechner. Wer den Server noch nicht kennt, dem erklärt unser Beitrag zur selbst gehosteten Workflow-Automatisierung mit n8n die Ausgangslage.

Zur Installation liefert das Repo mehr als zwei Installer: nod-arm64.dmg und nod-x64.dmg für den Mac, nod-Setup-x64.exe plus Laufzeitpaket und nod-install.ps1 für Windows. Dazu ein nod-install.sh für den Selbstbetrieb auf einem Server ohne grafische Oberfläche. Die Desktop-App ist also der bequemste Weg, aber nicht der einzige.

Die Modellhürde: Werkzeugaufrufe und 64.000 Token

Nod arbeitet vollständig über Tools; die Doku sagt das unmissverständlich: „A model that supports tool calls. Nod does all its work through tools, so a model without them can only chat." Und weiter: „At least 64,000 tokens of context. Nod's instructions and tools take about 20,000 tokens before your first message. Most servers start with 4,096, and some cut Nod's instructions off without an error."

Genau an diesem Satz verliert eine Nachbauerzählung schnell Präzision, also trenne ich drei Dinge:

  1. Ein Modell ohne Werkzeugunterstützung kann in Nod nur antworten, nie handeln. Das ist Konstruktion, kein Fehler.
  2. Ein Server mit werkseitig 4.096 Kontext fasst die komplette Anweisung nicht. Manche Server kürzen dann still, ohne Fehlermeldung; der Agent weiß dann nicht mehr, wer er ist.
  3. Nod selbst fährt unterhalb von 65.536 Token Kontext einen erkennbar abgespeckten Betrieb: gekürzte Anweisungen, Werkzeugbeschreibungen einzeln nachgeladen. Es läuft dann also mit weniger Rüstung weiter, statt komplett in eine Chat-Attrappe zu zerfallen.

Wer ein lokales Modell anhängen will, muss dem Server also zwei Dinge mitgeben: Werkzeugannahme und genügend Kontext. Nod nennt dafür in der eigenen Doku das Flag-Beispiel --enable-auto-tool-choice --tool-call-parser für vLLM.

Unsere Lane gegen diese Hürde gemessen

Wir betreiben am Standort eine eigene Inferenz-Lane: vLLM 0.32.0 mit vier Karten, davor LiteLLM als Gateway, darüber vier Harnesses im Alltag. Ich habe am 11.11.2026 read-only nachgemessen, ob diese Lane beide Nod-Hürden nimmt; für die Antwort aus dem Modell habe ich einen einzigen kleinen Probe-Request mit einem Rechenwerkzeug durch das Gateway geschickt.

MesseinheitNod-ForderungUnsere Lane, gemessen 11.11.2026Treffer
Werkzeugaufruf je Sonde (Anzahl)Pflicht, sonst nur ChatvLLM-Argumente --enable-auto-tool-choice --tool-call-parser qwen3_xml aktiv; Sonde antwortet mit finish_reason: tool_calls und den Argumenten {"a": 27, "b": 43}erfüllt
Kontext je Anfrage (Token)mindestens 64.000--max-model-len 220000, KV-Cache in nvfp4erfüllt
Systemlast vor erster Nachricht (Token)rund 20.000 laut AnbieterProbenachricht mit einem Werkzeug: 330 Prompt-Token; die 20.000 beschreiben Nods vollständige Werkzeugliste, das ist keine Größe unserer LaneHinweis

Messträger in allen drei Zeilen: das Modell flashnext-hybrid auf vier RTX 5090, gerouted über LiteLLM. Die zwei Hürden, die Nod aufstellt, nimmt unsere Lane nach dieser Messung beide. Nützlich ist der Test für jeden, der eine eigene Lane hat: Es sind exakt zwei Server-Argumente und ein Kontextwert, und die lassen sich in fünf Minuten prüfen, bevor der erste Auftrag schiefgeht.

Der Datenweg, wenn Nod Apps verbindet

Die ehrliche Frage zu so einem Programm ist nicht, was es kann, sondern wo die Bytes durchlaufen. Für Anmelde- und App-Verbindungen steht in der Doku wörtlich: „By default, app requests and results pass through n8n's hosted connection service and Composio. Source installs can select a trusted connection service." Composio ist dabei ein separater Drittanbieter für Werkzeuganbindungen. Wer Nod eine Gmail-Verbindung gibt, schickt Anfragen und Ergebnisse über diese zwei Fremddienste. Wer Nod aus dem Quellcode selbst betreibt, kann laut Doku einen eigenen Verbindungsdienst hinterlegen; die Desktop-App nutzt die Voreinstellung.

Zwei weitere Datenwege gehören zur Vollständigkeit. Die Startseite sagt offen, dass n8n neben Update-Prüfungen auch Nutzungsdaten empfängt; abschaltbar ist das jederzeit in den Einstellungen. Und: Anmeldelinks laufen bewusst nie über Messenger-Kanäle; sie öffnen immer den eigenen Browser, damit ein kompromittierter Messenger nicht an Logins kommt.

In Summe ergibt sich eine saubere Trennlinie: Der Modellverkehr läuft zu dem Anbieter, den wir selbst gewählt haben, bei eigenem Server also ins Haus. Der App-Verkehr läuft standardmäßig über fremde Dienste. Beides zusammen wissen ist die Grundlage für jede Entscheidung, ob das ins Haus passt.

Was unter der Haube liegt

Der Stapel, den das Repo selbst ausweist: TypeScript auf Node.js 24, Fastify als Server, React für die Oberfläche, PostgreSQL mit pg-boss für Warteschlangen, die Pi-Agent-Runtime als Kern, agent-browser für den Browser und Electron als Verpackung; Werkzeuge kommen über MCP, Verbindungen über Composio. Die Lizenzfrage prüfe ich grundsätzlich am Lizenztext des Repos, das Abzeichen im README wäre dafür kein Beleg: Die Datei LICENSE enthält hier den echten Apache-2.0-Text, die GitHub-API meldet dieselbe Lizenz.

Der Stand der Repository-Daten vom 11.11.2026: angelegt am 25.9.2026, 260 Stars, 35 Forks, 6 offene Issues, letzter Push am selben Tag. Sechs Wochen zwischen Anlage und öffentlicher Veröffentlichung sind knapp; für die Produktqualität würden wir daraus noch kein Urteil ableiten, aber die Frage nach dem Reifegrad dürfen wir mitnehmen. Als Anbieterangabe, von uns nicht nachgerechnet: n8n beziffert die Langzeitqualität des Gedächtnisses auf 93,2 Prozent im LongMemEval-Benchmark und beschreibt Kostengrenzen, bei denen der Agent sich ab fünf Dollar Verbrauch zurückmeldet.

Wer einsteigen kann und wer warten sollte

Für einen Mac- oder Windows-Platz, an dem ein Agent über den Tag verteilt Aufgaben erledigen soll, ist Nod einen Blick wert, gerade weil die Ausführung im Haus bleibt und das Modell frei ist. Zwei Prüfungen sollten vor dem ersten echten Auftrag erledigt sein. Erstens die Modellseite: Werkzeugannahme und mindestens 64.000 Kontext, beides nachgemessen; unsere Tabelle oben zeigt, wie das für die eigene Lane in fünf Minuten erledigt ist. Zweitens die Datenweg-Seite: Welche App-Verbindungen gehen über das Standard-Relais, und passt das zur eigenen Datenschutzlinie? Wer beides geklärt hat und dann Aktionen erlauben will, braucht zusätzlich eine Aufteilung, welche Aktionen ein Agent unbeaufsichtigt ausführen darf; unsere Stufen dafür stehen im Beitrag zu agenten-Freigaben und Klick-Ermüdung. Alles, was wir über KI im laufenden Betrieb geschrieben haben, läuft im Hub KI im Betrieb zusammen, und wer eine eigene Inferenz-Lane für solche Agenten aufziehen lassen möchte, findet uns über unsere IT-Leistung zu lokaler KI und Modellbetrieb. Mein konkreter Rat zum Schluss: Nod zuerst mit der eigenen Lane und ohne App-Verbindungen eine Woche mit Alltagsaufgaben fahren, Telemetrie in den Einstellungen prüfen, dann einzelne Verbindungen dazugeben.

Weiterführende Quellen

Fragen?
Kann ich Nod mit einem eigenen Modellserver komplett ohne Cloud-Betrieb nutzen?+

Beim Modell ja, bei den App-Verbindungen nein. Das Modell kann über einen eigenen OpenAI-kompatiblen Server laufen, dann geht der gesamte Modellverkehr im Haus ab. App-Verbindungen wie Gmail reichen Anfragen und Ergebnisse aber standardmäßig über den von n8n gehosteten Verbindungsdienst und Composio weiter. Wer den Quellcode selbst betreibt, kann laut Doku einen eigenen Verbindungsdienst hinterlegen.

Warum antwortet mein lokales Modell in Nod nur, statt zu handeln?+

Nod arbeitet vollständig über Werkzeugaufrufe. Ein Modell ohne Tool-Unterstützung kann deshalb nur chatten, das steht so in der Modell-Doku von Nod. Die zweite häufige Ursache ist der Kontext: Nod braucht mindestens 64.000 Token, weil Anweisungen und Werkzeuge rund 20.000 Token belegen. Die meisten lokalen Server starten werkseitig mit 4.096, und manche kürzen die Anweisung dann still, ohne Fehlermeldung.

Ist Nod dasselbe Produkt wie der n8n-Automation-Server?+

Nein, es ist ein eigenes Programm von n8n Labs. Der bekannte n8n-Server baut geteilte Workflows, in dem Fall mit mehreren Nutzern, Rollen und Freigaben. Nod ist als Einzelplatz für eine Person gebaut: eine Desktop-App mit eigener virtueller Maschine auf dem Rechner. Beide Produkte teilen sich die Marke und Teile der Verbindungs-Infrastruktur, sonst wenig.

Zurück zum BlogKI im Betrieb