n8n mit AI Assistant: Unser Produktionsstack für 2026

Wer n8n für ein Team betreibt, muss über das erste erfolgreiche Deployment hinaus planen. Workflows und Zugangsdaten müssen einen Containerwechsel überstehen, fehlgeschlagene Updates brauchen einen Wiederherstellungsweg, und jemand muss Ressourcenverbrauch und API-Guthaben im Blick behalten.

Der neue AI Assistant von n8n bringt weitere Entscheidungen mit sich. Er braucht Modellinferenz und eine Sandbox zum Erstellen von Workflows. Die Websuche ist optional, hilft aber beim Nachschlagen aktueller Dokumentation.

Dieser Artikel erklärt den Stack, den wir für ein kleines Team wählen würden: Sliplane für n8n und Managed PostgreSQL, Daytona für Sandboxes, Melious für die Inferenz und Brave Search für die Recherche. Die Registrierung, Umgebungsvariablen und das Deployment behandeln wir im ergänzenden Self-Hosting-Tutorial.

Der Stack auf einen Blick

Schauen wir uns die einzelnen Komponenten an und erklären, warum wir sie für diesen Stack gewählt haben. Dich interessieren nur die Zahlen? Direkt zur Kostenübersicht.

Anwendungshosting: mit einem gepflegten Container starten

Das n8n-Preset von Sliplane liefert ein versioniertes Image, ein persistentes Volume und einen generierten Verschlüsselungsschlüssel. Die Plattform übernimmt die Deployment-Oberfläche und den öffentlichen HTTPS-Endpunkt. Die Konfiguration von n8n bleibt in unserer Hand. Mehr dazu: So funktioniert das Deployment eines Dienstes.

Für ein kleines Team ist diese Arbeitsteilung praktisch. Du kannst Logs prüfen und über das Dashboard erneut deployen, ohne selbst einen Docker-Host zu warten. Neue n8n-Versionen musst du weiterhin vor dem Update testen und den Speicherverbrauch beobachten, wenn deine Workflows wachsen.

Wir würden mit mindestens 2 GB RAM für den Anwendungsserver beginnen und die Größe anhand der tatsächlichen Nutzung anpassen. Das ist eine Empfehlung für den Einstieg, keine Kapazitätsgarantie: Große Datenmengen bei Ausführungen und parallele Workflows können deutlich mehr benötigen. PostgreSQL bekommt in diesem Stack eigene Ressourcen.

Falls du noch zwischen einem VPS, verwaltetem Container-Hosting und n8n Cloud abwägst, lies zuerst unseren Vergleich der n8n-Hosting-Optionen.

Datenbank: PostgreSQL für eine planbare Wiederherstellung

SQLite ist praktisch, um n8n auszuprobieren. Für dieses Deployment würden wir Managed PostgreSQL anschließen, bevor der erste Workflow entsteht. Damit lassen sich Anwendungsdeployments und Datenbankwiederherstellung unabhängig voneinander durchführen.

Sliplane Managed PostgreSQL bietet ein Backup-Fenster von sieben Tagen mit Point-in-Time-Recovery. Eine Wiederherstellung erstellt eine weitere Datenbank. Du kannst die wiederhergestellten Daten also prüfen, bevor du die Verbindung der Anwendung umstellst. Diese zusätzliche Datenbank wird separat abgerechnet, solange sie besteht.

Zwei Details solltest du einplanen. Erstens handelt es sich um eine Verbindung zu einer verwalteten Datenbank: Gib die ausgehenden IP-Adressen des App-Servers frei und konfiguriere TLS mit Zertifikatsprüfung. Das Tutorial behandelt beides. Zweitens reicht ein Datenbankbackup allein nicht aus, um verschlüsselte n8n-Zugangsdaten wiederherzustellen. Bewahre den ursprünglichen N8N_ENCRYPTION_KEY sicher auf und sichere auch das Volume unter /home/node/.n8n.

Ein Wiederherstellungstest sollte eine konkrete Frage beantworten: Kann eine andere Person die Instanz wiederherstellen und ihre gespeicherten Zugangsdaten nutzen? Unser Leitfaden zum n8n-Betrieb behandelt die weiteren Aufgaben rund um Backups und Updates.

Sandbox: Daytona betreibt die Arbeitsumgebung des Builders

Die Sandbox des Assistenten dient dazu, Workflows zu erstellen und zu validieren. Nach dem Speichern werden diese Workflows in n8n ausgeführt. Daytona übernimmt somit eine andere Aufgabe als das Hosting von n8n oder die Ausführung gewöhnlicher Workflow-Nodes. Siehe n8ns Sandbox-Architektur.

n8n dokumentiert eine selbst gehostete Sandbox-Konfiguration, empfiehlt für den Produktionsbetrieb aber Daytona. So müssen wir die Sandbox-API und die privilegierte Runner-Infrastruktur nicht zusätzlich auf unserem App-Server betreiben. n8n erstellt die Arbeitsumgebungen über die API von Daytona.

Dafür kommen ein weiteres Konto und mögliche Fehlerquellen hinzu. Ein Build kann scheitern, weil der API-Schlüssel abgelaufen ist, die Organisation ihr Ressourcenkontingent erreicht hat oder die Sandbox eine benötigte Website nicht aufrufen kann. Daytonas Netzwerkbeschränkungen hängen vom Kontotarif ab. Kostenloses Guthaben allein garantiert daher nicht den Zugriff auf alles, was ein Build benötigen könnte.

Lass das automatische Aufräumen inaktiver Sandboxes aktiviert und überwache neben der Rechenleistung auch den Speicher. Eine gestoppte Sandbox kann weiterhin Speicherkosten verursachen. In Daytonas Abrechnungsleitfaden steht, wie sich die Kosten je nach Lebenszyklusstatus ändern.

Inferenz: Melious nutzen und das Modell bewerten

Melious bietet gehostete Inferenz auf europäischer Infrastruktur über eine OpenAI-kompatible API. Dadurch können wir n8ns Unterstützung für eigene Modellendpunkte nutzen, ohne Hardware für den Modellbetrieb auf dem Anwendungsserver vorzuhalten.

Anbieter und Modell sind zwei getrennte Entscheidungen. Unser Tutorial verwendet glm-5.2 als Ausgangspunkt. Der zugehörige Integrationsleitfaden behandelt Modell-Nodes in Workflows. Der integrierte AI Assistant wird anders konfiguriert: Er kombiniert n8ns eigenen Endpunkt mit der Melious-API. Diese konkrete Kombination braucht auf deiner eingesetzten Version noch einen Abnahmetest.

Bevor sich ein Team darauf verlässt, solltest du mehrere Workflows aus seinem tatsächlichen Arbeitsalltag ausprobieren. Halte fest, ob jeder erstellte Workflow läuft, wie viele Korrekturen nötig sind, wie lange der Vorgang dauert und was er kostet. Bewahre diese Beispiele für spätere Modellwechsel auf. Ein niedriger Tokenpreis kann sich als teuer erweisen, wenn das Modell wiederholt keinen funktionierenden Workflow erstellt.

Europäische Inferenz legt außerdem nicht fest, wo alle anderen Komponenten dieses Stacks Daten verarbeiten. Modellanfragen gehen an Melious, Sandbox-Aufgaben an Daytona, Suchanfragen an Brave. Die n8n-Daten liegen in den gewählten Hosting- und Datenbankregionen. Prüfe diesen gesamten Datenweg anhand der Anforderungen deines Teams.

Suche: dem Assistenten aktuelle Quellen zugänglich machen

Brave Search liefert Web-Ergebnisse, wenn der Assistent aktuelle Dokumentation oder andere externe Informationen benötigt. Die Suche ist in n8ns Assistentenkonfiguration optional. Wir nehmen sie auf, weil sich API-Dokumentation ändert und die Trainingsdaten eines Modells veraltet sein können.

Verwende den API-Tarif Search. Zum Zeitpunkt der Veröffentlichung kostet er 5 US-Dollar pro 1.000 Anfragen und enthält jeden Monat 5 US-Dollar kostenloses Guthaben. Siehe die Brave-API-Tarife.

Im Produktionsbetrieb zählt die dauerhafte Verfügbarkeit. Ist das Guthaben aufgebraucht und kein bezahltes Guthaben vorhanden, stoppt die Recherche. Lege ein Monatsbudget fest und prüfe, ob eine Testfrage tatsächlich Brave aufruft: Eine überzeugende Antwort mit URL beweist noch nicht, dass die Suchintegration funktioniert.

Was kostet der gesamte Stack?

Der kleinste Sliplane-Server und die Datenbank kosten zusammen 28 €/Monat zzgl. MwSt., zuzüglich API-Nutzung. Unsere Empfehlung, mit einem größeren App-Server mit 2 GB RAM zu starten, erhöht diesen Grundbetrag. Prüfe vor dem Kauf die aktuellen Preise von Sliplane, Daytona, Melious und Brave.

Kostenloses Guthaben erleichtert das Ausprobieren. Für ein dauerhaftes Budget solltest du mehrere realistische Sitzungen zum Erstellen von Workflows messen: Eine Nutzeranfrage kann mehrere Inferenzaufrufe und Suchanfragen auslösen. Modellaufrufe innerhalb gespeicherter Workflows verursachen zusätzliche Nutzung, unabhängig vom Erstellen mit dem Assistenten.

Was braucht der Stack für den Einsatz im Team?

Bevor du die Instanz übergibst, etabliere vier Routinen:

• Wiederherstellung: Teste eine Datenbankwiederherstellung mit dem ursprünglichen Verschlüsselungsschlüssel und prüfe die wiederhergestellten Zugangsdaten.
• Updates: Fixiere die n8n-Image-Version, prüfe neue Releases und führe deine Beispielworkflows nach Änderungen erneut aus.
• Monitoring: Beobachte Workflow-Fehler getrennt von Assistentenfehlern und behalte Guthaben sowie Kontingente der Anbieter im Blick.
• Verantwortung: Lege fest, wer Abrechnung, ablaufende Schlüssel und Störungen übernimmt.

Ein Inferenzausfall kann einen neuen KI-gestützten Build verhindern, während bestehende Workflows normal weiterlaufen. Ein Workflow, der denselben Anbieter aufruft, hat eine eigene Abhängigkeit und braucht eine eigene Fehlerbehandlung. Berücksichtige diese Fälle getrennt, wenn du Alarme einrichtest.

Bereit für die Einrichtung? Das ergänzende Tutorial zum Self-Hosting von n8n mit AI Assistant beginnt bei der Registrierung und führt dich durch Datenbank, API-Schlüssel, Deployment und Funktionstests.