Vier Stunden. Ein GitHub-Repo, das ich nicht geschrieben habe. Keine SSH-Shell, kein Setup-Script, kein Anthropic-Account. Und am Ende: eine funktionierende KI namens Caterina, die mich auf Telegram mit meinem Namen anspricht, sich an vergangene Gespräche erinnert und mir das Wetter in beliebigen Städten sagt.
Das ist kein Tutorial. Das ist ein ehrlicher Bericht darüber, was wirklich passiert, wenn man ein komplexes, selbst-gehostetes AI-Agenten-System in eine bestehende Infrastruktur zwingt, die es nicht kennt.
Was n8n-claw eigentlich ist
Das Repo heißt n8n-claw. Es ist kein einfaches n8n-Template. Es ist ein vollständiges, selbst-gehostetes AI-Agenten-System: PostgreSQL mit pgvector für semantisches Memory, PostgREST als REST-Schicht, Kong als API-Gateway, nginx als Reverse Proxy, n8n als Workflow-Engine, alles in Docker Compose. Designed für eine nackte Ubuntu-VPS mit direktem SSH-Zugang und einem Setup-Script, das die Welt neu erschafft.
Ich habe weder eine nackte VPS noch SSH-Zugang zu meinem Hetzner-Server. Ich habe Coolify. Das ist der Unterschied zwischen einer Küche und einem Restaurantbetrieb: dieselben Zutaten, aber eine völlig andere Logik dahinter.
Meine Kernthese: Ein gut durchdachtes Open-Source-Repo lässt sich in wenigen Stunden auf eine fremde Infrastruktur portieren, wenn man die Abstraktionsebenen versteht und nicht versucht, das Original zu imitieren, sondern die Funktion zu replizieren. Das ist Vibe Coding in der Praxis: nicht debuggen was kaputt ist, sondern verstehen was gemeint war.
Die Entscheidungen, bevor die erste Zeile geändert wurde
Das Erste, was ich gemacht habe: die docker-compose.yml komplett gelesen. Nicht überflogen. Gelesen.
Was ich dabei erkannt habe: Kong und nginx erfüllen in diesem Setup genau eine Funktion. Sie leiten HTTP-Traffic weiter und stellen HTTPS bereit. In meiner Coolify-Umgebung macht das bereits Traefik. Beides parallel zu betreiben wäre nicht nur redundant, es wäre ein Rezept für Restart-Loops.
Also: Kong raus. nginx raus. Traefik-Labels rein. Das coolify-Netzwerk als externes Netzwerk deklariert. Und alle internen Services, die vorher über Kong mit PostgREST kommuniziert haben, kommunizieren jetzt direkt über http://rest:3000.
Das klingt simpel. Der entscheidende Moment war zu verstehen, dass {{SUPABASE_URL}} in den n8n-Workflows kein echter Supabase-Cloud-Endpunkt ist. Es ist ein Platzhalter für die eigene PostgREST-Instanz. Dieser Platzhalter steckte in acht verschiedenen Workflows, und Coolify ersetzt ihn nicht automatisch.
Der PostgreSQL-Moment: 96 Tabellen ohne Terminal-Magie
Das originale Setup-Script spielt vier SQL-Migrations-Dateien ein. Coolify unterstützt keine lokalen Datei-Mounts aus dem Repository, also gibt es keinen automatischen Weg, diese Dateien in den Container zu bekommen.
Was es gibt: das Coolify-Terminal. Direkt im Browser, direkt im laufenden Container.
Ich habe die vier Migrations-Dateien manuell in den Container kopiert, eine nach der anderen via psql ausgeführt und das Ergebnis geprüft. Am Ende: 96 Tabellen, Funktionen, Indexes, Row-Level-Security-Grants. Das Schema stand.
Ich erwähne das, weil es der Moment ist, den viele überspringen wollen. Sie suchen nach dem magischen Knopf, der alles automatisch einspielt. Den gibt es manchmal nicht. Und wenn es ihn nicht gibt, ist es kein Problem. Es ist eine Viertelstunde Arbeit.
Anthropic durch Gemini ersetzen: mehr als ein Modell-Swap
Das ist der Teil, der technisch am interessantesten war.
Das Originalrepo ist auf OpenAI und Anthropic ausgelegt. Nicht nur die Chat-Completions, sondern auch das Embedding-System. OpenAI-Embeddings haben 1536 Dimensionen. Google Gemini Embedding 001 hat 768 Dimensionen. Das sind keine kompatiblen Formate. Ein falsches Embedding in der falschen Dimension-Größe macht die Vektorsuche kaputt.
Ich habe das gesamte Embedding-System neu geschrieben:
Das Datenbankschema musste zuerst angepasst werden. Die vector(1536)-Spalten wurden auf vector(768) geändert. Das bedeutet: alle pgvector-Indexes neu erstellen, weil der Operator-Klassen-Typ dimensionsabhängig ist.
Dann die vier Memory-Workflows in n8n: Memory Save, Memory Search, Memory Update, Memory Delete. Alle vier hatten OpenAI-spezifische Nodes und Embedding-Logik. Alle vier neu geschrieben für das Google Gemini Embedding-Modell, das übrigens gemini-embedding-001 heißt und nicht text-embedding-004, wie ich zunächst angenommen hatte. Dieser Fehler kostet einen zehn Minuten.
Danach: die 15 Workflow-JSON-Dateien in n8n importiert. Die Anthropic-Nodes in den Chat-Workflows durch Google Gemini Chat Model ersetzt. Credentials für Telegram, PostgreSQL und Google Gemini API angelegt und verknüpft.
Als KI-Berater, der seit Jahren EPU und KMU in Österreich beim Einstieg in generative KI begleitet, sage ich das ohne Übertreibung: der Wechsel von einem Anbieter zu einem anderen ist technisch lösbar. Der kritische Punkt ist das Verstehen der Datenstruktur, nicht das Ersetzen eines API-Aufrufs.
Zur Klarheit, weil die Begriffe oft durcheinandergeraten
Embedding: Eine numerische Darstellung von Text als Vektor. Je ähnlicher zwei Texte semantisch sind, desto näher liegen ihre Vektoren im mehrdimensionalen Raum. So kann ein System nicht nach exakten Keywords suchen, sondern nach Bedeutung.
Vektorsuche: Eine Datenbankabfrage, die nicht „finde diesen Text“, sondern „finde den bedeutungsmäßig ähnlichsten Text“ fragt. Das ist die Grundlage für Langzeit-Memory in AI-Agenten.
PostgREST: Ein Dienst, der eine PostgreSQL-Datenbank automatisch als REST-API nach außen verfügbar macht. Kein eigener Backend-Code nötig.
Das hängt zusammen: Embeddings ermöglichen Vektorsuche. PostgREST macht die Vektordatenbank via HTTP aus n8n-Workflows heraus erreichbar. Das ist das Rückgrat von Caterinas Memory.
Caterina: die Persönlichkeit, die am Ende debuggt
Das Projekt heißt nicht „AI Agent System“. Es heißt Caterina. Benannt nach Caterina Buti, der Mutter von Leonardo da Vinci.
Ich habe eine Persönlichkeit in der Datenbank konfiguriert: warm, direkt, fürsorglich. Spricht immer auf Deutsch. Spricht mich immer mit meinem Namen an. Das ist kein Gimmick. Es ist eine bewusste Entscheidung, das System als Gegenüber zu gestalten, nicht als Tool.
Was mich dabei überrascht hat: die Persönlichkeit macht das Testen angenehmer. Wenn die KI einen Fehler macht und trotzdem warm antwortet, bleibt man ruhiger. Das klingt banal. Es ist es nicht.
Die Hürden, die niemand im Tutorial erwähnt
Kong und die Restart-Schleife. Coolify legt fehlende Datei-Mounts als leere Ordner an. Kongs Konfiguration ist eine Datei. Wenn ein Ordner existiert, wo eine Datei erwartet wird, startet Kong in einer Schleife neu. Diagnose: fünfzehn Minuten. Lösung: Kong entfernen, PostgREST direkt ansprechen.
Die chat_id, die nicht übergeben wurde. Reminders in n8n benötigen die Telegram-Chat-ID, um Nachrichten zu senden, wenn der User gerade nicht aktiv ist. Diese ID lag nicht im Standard-Memory-Kontext. Lösung: Session-Block im System-Prompt verankert und einen Hardcoded-Fallback eingebaut, bis das Memory-System sie zuverlässig speichert.
n8n 2.x Task Runner Sandbox. Die neue Sandbox in n8n 2.x hat strengere Regeln als ältere Versionen. Kein var in try/catch. Kein Object.assign. Tool-Nodes müssen String-Returns liefern, keine JSON-Arrays. Wer Code aus älteren Tutorials kopiert, wundert sich über kryptische Execution-Fehler. Die Lösung ist immer dieselbe: die Fehlermeldung lesen, den Scope des Code-Nodes verstehen, neu schreiben.
Was funktioniert. Was nicht. Und was das bedeutet.
Das sind keine Bugs. Das sind Baustellen.
Folgendes funktioniert: Telegram-Konversation mit Caterina in Echtzeit. Langzeit-Memory mit semantischer Suche, Speichern, Updaten und Löschen. Reminder mit korrekter Wiener Zeitzone. Wetter via Open-Meteo MCP für beliebige Städte. Task-Manager mit CRUD. User-Profil, aus dem Caterina weiß, wer ich bin.
Folgendes bleibt deaktiviert: Heartbeat und Memory Consolidation haben hartkodierte Anthropic-API-Calls. Workflow Builder braucht Claude Code CLI. Und das sind nur die Dinge, die ich heute schon weiß.
Was ich noch nicht weiß: wie stabil das System unter echter Dauerlast läuft. Ob die Vektorsuche bei wachsender Memory-Menge performant bleibt. Ob Caterinas Persönlichkeit über lange Konversationsverläufe konsistent bleibt oder anfängt zu driften. Ob die Reminder-Logik wirklich zuverlässig ist, wenn ich zwei Wochen nicht aktiv teste.
Das hier ist eine Basis. Kein fertiges Produkt. Vier Stunden Arbeit können den Rahmen aufstellen, aber sie können nicht ersetzen, was nur Zeit und echte Nutzung zeigen: ob das System hält, was es verspricht.
Ich sage das bewusst, weil ich es leid bin, Build-Logs zu lesen, die so klingen, als wäre am Ende alles perfekt. Das ist es nie. Heute ist Caterina am Leben. Ob sie in einem Monat noch läuft, noch besser läuft und mehr kann, das entscheidet sich in den nächsten Wochen.
Was das bedeutet
Ich habe heute bewiesen, dass ein komplexes, selbst-gehostetes AI-Agenten-System mit semantischem Memory, Telegram-Interface und vollständigem Task-Management in unter vier Stunden auf einer bestehenden Coolify-Infrastruktur deployt werden kann, ohne Root-Zugang, ohne Setup-Skript und mit einem anderen AI-Anbieter als im Original vorgesehen.
Das ist kein Rekord. Das ist ein Maßstab.
Wer die Abstraktionsebenen einer Docker-Compose-Umgebung versteht und nicht darauf besteht, das Original zu klonen, kann fast jedes öffentliche AI-Agenten-Repo in seine eigene Infrastruktur integrieren. Der Trick ist nicht das Kopieren. Der Trick ist das Verstehen der Funktion hinter dem Code.
Caterina läuft. Auf Hetzner. Mit Coolify. Mit Google Gemini. Ohne einen einzigen SSH-Befehl. Das ist der Anfang, nicht der Abschluss. Ich berichte weiter.
Häufige Fragen zu n8n AI-Agenten auf Coolify
Kann ich n8n-claw auch ohne Coolify deployen?
Ja. Das Originalrepo ist für eine nackte Ubuntu-VPS mit SSH designed. Coolify ist eine Schicht obendrüber, die das Deployment vereinfacht, aber auch andere Anforderungen stellt, besonders was Datei-Mounts und Reverse Proxy betrifft.
Warum PostgREST statt einer direkten Datenbankverbindung aus n8n?
n8n kann PostgreSQL direkt ansprechen, aber der ursprüngliche Stack nutzt PostgREST als REST-Abstraktionsschicht, weil mehrere Services (und theoretisch externe Clients) auf dieselbe Datenbank zugreifen. Für ein Single-User-Setup ist es eine Ebene mehr Komplexität, aber sie lässt sich nicht ohne Umschreiben der Workflows entfernen.
Welche Gemini-Modelle eignen sich für dieses Setup?
Für Chat: Gemini 2.5 Flash. Für Embeddings: gemini-embedding-001 mit 768 Dimensionen. Das Embedding-Modell ist entscheidend: das Datenbankschema muss zur Dimension des Modells passen, sonst schlägt die Vektorsuche stumm fehl.
Lässt sich das System auf mehrere Nutzer ausweiten?
Technisch ja, das Datenbankschema unterstützt mehrere User-Profile. Aber das Telegram-Bot-Setup im Originalrepo ist Single-User-optimiert. Für Multi-User-Szenarien braucht es eigene Routing-Logik.
