"Multica auf Hetzner: Build-Log für selbst gehostete Claude-Agenten"

"## Ich habe Multica auf einem Hetzner-VPS selbst gehostet. Hier ist das Build-Log.\n\nDie Rechnungsbenachrichtigung von Claude Managed Agents landete um 23:03 Uhr an einem Samstag in meinem Posteingang. Drei Sessions, die während eines Client-Sprints länger liefen als beabsichtigt — eine davon war über einen Zeitraum "inaktiv, aber technisch gesehen aktiv" — den ich in meiner unendlichen Weisheit nicht pausiert hatte. Die Rechnung war nicht katastrophal. Sie war dennoch hoch genug, um innezuhalten und eine Frage zu stellen, die ich seit zwei Wochen verdrängt hatte: Wenn ich Coding-Agenten als Teammitglieder einsetze, brauche ich dafür wirklich Anthropics Cloud?\n\nEin kurzer Hinweis zum Namen, bevor wir weitermachen. Die Videozusammenfassung, mit der ich arbeitete, nannte dieses Tool Multimodal. Das eigentliche Projekt auf GitHub, das ich installiert habe, heißt Multica — das Repo ist multica-ai/multica, das CLI-Binary ist multica und der Daemon ist multica daemon. Für den Rest dieses Beitrags verwende ich den echten Namen, damit die Befehle in diesem Log kopierbar und nicht nur wunschdenken sind.\n\nMultica versteht sich als Open-Source-Managed-Agents-Plattform: eine Schicht, die Terminal-Coding-Agenten wie Claude Code, Codex CLI und OpenCode in kollaborative Teammitglieder verwandelt, denen man Issues zuweisen, mit denen man direkt chatten und für die man wiederkehrende Aufgaben einplanen kann. Das Ganze ist selbst hostbar. Das Ganze läuft auf Docker. Und das Ganze ersetzte, sobald ich es am Laufen hatte, etwa 80 % dessen, was ich an Anthropics Managed Runtime bezahlt hatte — zum Preis eines VPS für 4,49 € und einer mäßig lästigen Auth-Umgehung.\n\nDies ist das Build-Log. Die Hetzner-Box, die ich ausgewählt habe, das Docker-Compose-Hochfahren, die genaue Env-Datei-Änderung, die mich am kaputten Login-Bildschirm vorbeibrachte, der multica daemon-Aufruf, der erste Agent, den ich erstellt habe, der Autopilot-Cron, den ich als Ersatz für eine Claude-Routine eingerichtet habe, und der ehrliche Vergleich am Ende. Wenn sich etwas auf meiner Maschine anders verhielt als die Dokumentation versprach, weise ich darauf hin — anstatt so zu tun, als wäre der Weg reibungslos gewesen.\n\n## Warum ich der Managed-Agents-Rechnung nicht mehr vertraute\n\nClaude Managed Agents startete am 8. April 2026 in der Public Beta. Zwei Wochen später hatte ich vier Routinen, die nach Plan liefen, einen Agenten, der auf Webhooks reagierte, und eine Session-Stunden-Abrechnungszeile, die sich sehr anders verhielt als eine typische API-Abrechnung. Managed Agents rechnet in zwei Dimensionen ab — Standardtokentarife plus 0,08 $ pro Session-Stunde aktiver Laufzeit — und die zweite ist diejenige, die einen überrascht. Sonnet-4.6-Token kosten 3 $ Input / 15 $ Output pro Million. Das ist vorhersehbar. Eine Session, die "running" anzeigt, während ein Agent auf ein langsames git clone wartet — das ist ein Zähler, den ich nicht ticken sehe.\n\nDas ist kein Skandal. Anthropic ist transparent über die Preise, und der Laufzeit-Zähler pausiert, wenn die Session nicht aktiv arbeitet. Das Problem ist nicht Fairness. Das Problem ist Kontrolle. Ich wollte auf die Wattstunde genau wissen, was meine Agenten kosten und tun. Ich wollte einen sechs Stunden laufen lassen, ohne auf ein Dashboard zu schauen. Ich wollte ihn auf ein privates Repo richten, ohne einer Managed Cloud Zugriff darauf zu gewähren. Und ich wollte das zugrunde liegende Modell tauschen können — Claude, GLM-4.6, was auch immer Open Code Zens Stealth-Modell der Woche ist — ohne den Plan zu wechseln.\n\nMultica löst alle vier Punkte. Du betreibst die Plattform auf deiner eigenen Hardware. Du installierst die Coding-Agent-CLIs auf dieser Hardware. Du gibst Multica die API-Schlüssel. Es weist deinen Agenten Issues zu. Du schaust zu, wie es arbeitet. Deine Rechnung ist das, was das zugrunde liegende Modell kostet, plus der VPS.\n\n## Warum Hetzner — und welche Box ich gewählt habe\n\nIch habe versucht, diese Art von Workloads früher auf günstigeren Hosts auszuführen. Der $4/Monat-Droplet, den ich letzten Herbst für einen Claude-Code-Daemon verwendet habe, hatte nicht genug RAM, um drei Docker-Container plus einen Agenten, der einen Node-Workspace startet, zu betreiben. Multicas Standard-Stack besteht aus drei Containern — einem Go-Backend, einem Next.js/TypeScript-Frontend und einer Postgres-Instanz für die Sitzungsspeicherung — und wenn einem Agenten eine Aufgabe zugewiesen wird, startet der Daemon den CLI-Prozess auf derselben Maschine. Die Größenfrage lautet also nicht "Kann es den Stack starten?", sondern "Kann es den Stack starten und gleichzeitig Claude Code eine React-App bauen lassen, ohne dass etwas durch OOM gekillt wird?"\n\nIch entschied mich für Hetzner aus zwei Gründen. Erstens ist das Preis-Leistungs-Verhältnis im Jahr 2026 immer noch absurd gut. Zweitens laufen die neuen CX-Plan-Shared-vCPU-Boxen auf Ampere-Altra-ARM-Silicon und die größeren Intel/AMD-Geschwister auf der x86-Seite, sodass ich das je nach Toolchain besser passende auswählen konnte. Nach Hetzners Preisanpassung vom 1. April 2026 stieg der CX22 von 3,29 € auf 4,49 €/Monat — immer noch 2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB Traffic — und die nächsthöhere Stufe, CPX21 auf dediziertem AMD, liegt bei rund 7,99 €/Monat. Ich startete auf dem CX22, nur um zu sehen, ob die günstigste realistische Box den Stack tatsächlich halten kann.\n\nKurze Antwort: Ja, für einen oder zwei gleichzeitig laufende Agenten. Wenn du vier Claude-Code-Sessions parallel betreiben möchtest, wechsle zum CPX21 oder höher. Der CX22 lief gut für einen einzelnen Retrieval-Agenten, der von einem privaten GitHub-Repo zog, aber bei einer zweiten gleichzeitigen Aufgabe begann er, auf Swap zu pagen.\n\nBevor ich irgendetwas installierte, erledigte ich das Ding, das ich immer vergesse und später bereue: Ich sperrte SSH ab. Nur Schlüssel, Root-Passwort-Login deaktiviert, ufw erlaubt nur 22, 80, 443 und welchen Port Multicas Frontend verwenden würde. Ich installierte auch Docker Engine 27.x (aktuelle LTS-Version vom April 2026) mit dem offiziellen Convenience-Script und nicht der Ubuntu-Repo-Version, da Multicas Compose-Datei neuere Healthcheck-Syntax verwendet.\n\n## Das Hochfahren: drei Container, eine Env-Datei, ein kaputtes Login\n\nDie Multica-README bietet zwei Installationspfade. Der erste ist der vorgesehene — installiere die CLI lokal, verweise sie auf Multica Clouds gehostete UI und lass die das Backend erledigen. Das ist der schmerzlose Weg. Es ist auch nicht der Weg, für den ich hier war.\n\nDer zweite ist vollständiges Self-Hosting. Du klonst das Repo, passt eine Env-Datei an und fährst den gesamten Stack mit Docker Compose hoch.\n\nbash\ngit clone https://github.com/multica-ai/multica.git\ncd multica\ncp .env.example .env\ndocker compose config\ndocker compose up -d\n\n\nDie drei Services: db (Postgres 16), backend (Go API, Port 8080), frontend (Next.js, Port 3000). Die Healthchecks verketten sie korrekt.\n\nDas erste Hochfahren dauerte etwa neunzig Sekunden. docker compose ps zeigte alle drei als gesund. Ich öffnete das Frontend unter http://<vps-ip>:3000 und erhielt einen Login-Bildschirm.\n\nHier stieß ich an eine Wand. Multicas Standard-Auth-Flow sendet einen "aktuellen Code" über den Cloud-Service. Wenn du vollständig selbst hostest, kommt dieser Code nie an. Du starrst auf ein sechsstelliges Eingabefeld, das sich nie auflöst.\n\nDie Umgehung: Öffne .env und setze zwei Werte:\n\nbash\nAPP_ENV=development\nRECENT_API_KEY=\n\n\nAPP_ENV=development weist das Backend an, die Cloud-Code-Verifikation zu überspringen und jeden sechsstelligen Code zu akzeptieren. RECENT_API_KEY leer zu lassen entfernt die Cloud-Anmeldedaten. Zusammen versetzen sie dich in einen Dev-Mode-Login, bei dem die erste E-Mail-Adresse ein Konto erstellt und jeder sechsstellige Code funktioniert.\n\nNach dem Speichern: docker compose down && docker compose up -d. Ich tippte 123456 und war drin.\n\nDas ist es wert, explizit zu sagen: APP_ENV=development ist kein Produktions-Auth-Modus. Es ist in Ordnung, wenn der VPS in einem Tailscale-Mesh-VPN ist und kein öffentlicher Traffic Port 3000 erreicht. Es ist nicht in Ordnung, wenn das Frontend dem offenen Internet ausgesetzt ist.\n\n## Den Daemon und die Runtimes registrieren\n\nMit der laufenden UI ist der nächste Schritt das Einbinden der eigentlichen Arbeitsschicht. Die UI ist der Ort, an dem du Agenten und Issues definierst; ein separater Daemon-Prozess nimmt die Arbeit auf und führt die Coding-Agent-CLIs aus.\n\nbash\ncd /opt/multica\nsudo cp ./bin/multica /usr/local/bin/\nmultica --version\nmultica auth login --server http://localhost:8080 --token <API_TOKEN>\nmultica daemon\n\n\nBeim ersten Start erkennt der Daemon automatisch, welche Agenten-CLIs installiert sind. Unterstützt: claude, codex, openclaw, opencode, hermes, gemini, pi, cursor-agent. Ich installierte Claude Code und OpenCode. Beide erschienen innerhalb von fünf Sekunden als "connected".\n\nDas API-Token-Modell ermöglicht es dir, den Daemon auf mehreren Maschinen gegen eine UI zu betreiben — eine echte Multi-Maschinen-Agenten-Flotte, ohne jemandes Cloud zu berühren.\n\nIch verpackte den Daemon in eine systemd-Unit:\n\nini\n[Unit]\nDescription=Multica agent daemon\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nType=simple\nUser=mejba\nWorkingDirectory=/home/mejba\nExecStart=/usr/local/bin/multica daemon\nRestart=always\nRestartSec=5\n\n[Install]\nWantedBy=multi-user.target\n\n\nbash\nsudo systemctl daemon-reload\nsudo systemctl enable --now multica-daemon\n\n\n## Mein erster Agent: ein Retrieval-Bot für meine eigenen Notizen\n\nIch baute einen NotesBot — einen Agenten mit Zugriff auf mein privates Obsidian-Notiz-Repo, der Fragen beantwortet, ohne dass ich in Markdown-Dateien wühlen muss.\n\nDas Erstellen eines Agenten erfordert zwei Felder: einen Namen und einen System-Prompt.\n\n\nYou are NotesBot, a focused retrieval agent working against a cloned\ncopy of my private notes repository located at /workspaces/notes.\n\nWhen I assign you an issue, treat the issue body as a question. Your\njob is to:\n\n1. Grep the repo for the most relevant notes (use ripgrep, not find).\n2. Read the top 3-5 candidate files in full before answering.\n3. Respond with: a direct answer, the filenames you used as sources\n (as relative paths from the repo root), and a \"confidence\" line\n that is one of: high / medium / low.\n4. If you can't find anything relevant, say so explicitly and suggest\n three adjacent queries I might try instead.\n\nNever modify files. Never create new notes. You are read-only.\nUse opencode with the zen big-pickle model unless told otherwise.\n\n\nFür NotesBot richtete ich ihn auf OpenCode mit dem Modell zen/big-pickle aus (GLM-4.6 — 200K Kontext, während des aktuellen Fensters kostenlos). Der Daemon löst dies zu etwas wie folgendem auf:\n\nbash\nopencode run --model zen/big-pickle --non-interactive \\\n --workspace /workspaces/notes-<task-id> \\\n --prompt-file /tmp/multica-<task-id>-prompt.txt\n\n\nMultica ist keine neue Runtime — es ist ein Orchestrator, der an Runtimes auslagert, die du bereits kennst.\n\nMein erstes Issue: "Welche meiner Notizen behandeln die Unterscheidung zwischen 'open loops' und 'pattern interrupts' in der Artikelstruktur?" Der Agent nahm es innerhalb von vier Sekunden auf, und zweiundzwanzig Sekunden später postete NotesBot seine Antwort mit drei Quelldateinamen und einem "high"-Konfidenz-Flag.\n\n## Autopilot einrichten: das Open-Source-Pendant zu Claude Routines\n\nClaude Routines (gestartet am 9. April 2026) führt geplante Prompts auf Anthropics Infrastruktur aus — stündlich, täglich, an Werktagen, wöchentlich oder bei Webhook/GitHub-Events. Begrenzt auf 5/15/25 Ausführungen pro Tag für Pro/Max/Team.\n\nMulticas Antwort ist Autopilot — ein Planer für wiederkehrende Aufgaben, der in das Issue-System eingebunden ist.\n\nMeine Konfiguration:\n- Agent: NotesBot\n- Prompt: Scan notes modified in the last 24 hours. List any tool or product name mentioned for the first time in my notes history. For each, give a one-line context of where it appeared.\n- Takt: 0 9 * * * (täglich um 9 Uhr)\n- Zeitzone: Europe/London\n\nEhrlich sein darüber, was Autopilot nicht hat: nur geplante Trigger. Kein API-Webhook-Trigger, kein GitHub-Event-Trigger. Und Agenten verschieben Aufgaben in In Review, aber nicht in Done — der Mensch muss abschließen.\n\n## Ehrlicher Vergleich: Multica Self-Host vs. Claude Managed Agents\n\nKosten: Self-Host gewinnt deutlich. 4,49 €/Monat VPS, kein 0,08 $/Session-Stunde-Zähler. Bei meiner Nutzung amortisiert sich der VPS in der ersten Woche.\n\nKontrolle: Self-Host gewinnt. Ich kann den Daemon pausieren, die Postgres-Session-Tabelle einsehen, Daemon-Logs Zeile für Zeile lesen und bei feststeckenden Aufgaben eingreifen. Kein Drittanbieter-Zugriff auf private Repos.\n\nTrigger-Oberfläche: Claude Managed Agents gewinnt. Routines unterstützen Zeitplan + Webhook + GitHub-Trigger. Multica Autopilot unterstützt nur Zeitpläne.\n\nUX-Politur: Claudes Oberfläche ist ausgefeilter. Multica wirkt wie ein früheres Stadium.\n\nMulti-Agent / Multi-Maschine: Self-Host gewinnt by design. Weise mehrere VPS-Daemons an eine Multica-UI.\n\nZuverlässigkeit: Claudes Runtime ist Anthropics Runtime — Uptime, die ich auf einem CX22 nicht erreichen kann.\n\nWo ich beides einsetzen würde: Claude Managed Agents für GitHub-Event-Workflows. Multica Self-Host für Kostenersparnis, Kontrolle und Szenarien mit privaten Daten.\n\n## Sicherheit: das Eine, das du richtig machen musst\n\nAPP_ENV=development im offenen Internet akzeptiert jeden sechsstelligen Code. Das ist schlimmer als keine Auth.\n\nWeg eins: Tailscale-Mesh-VPN. Installiere Tailscale (curl -fsSL https://tailscale.com/install.sh | sh), konfiguriere ufw so, dass die Ports 3000/8080/SSH nur über tailscale0 erreichbar sind. Das Frontend unter http://100.x.y.z:3000 ist nur von deinen eigenen Geräten aus erreichbar.\n\nWeg zwei: vollständig lokal. Betreibe den gesamten Stack auf einem Laptop oder Heimserver, der nie das öffentliche Internet berührt.\n\nWelchen Weg du auch wählst: Halte Docker-Images aktuell, halte den Host-Kernel gepatcht und behandle APP_ENV=development als ausschließlich für private Netzwerke.\n\n## Was ich als Nächstes bauen würde\n\n(1) CI an Multicas Issue-Erstellungs-API anbinden, damit fehlgeschlagene Builds automatisch Debug-Issues erzeugen. (2) Einen zweiten VPS-Daemon betreiben, der einem "Reviewer"-Agenten mit einem anderen Modell für Second-Opinion-Passes auf Agenten-PRs gewidmet ist.\n\nDie Claude-Managed-Agents-Rechnung ist seit dem Umzug von Retrieval- und geplanter-Prompt-Arbeit zu Multica um 60 % gesunken. Der Session-Stunden-Zähler ist eine deutlich kleinere Posten.\n\nWenn du dieselbe Frage gestellt hast, die ich an jenem Samstagabend gestellt habe — Brauche ich diese Cloud wirklich für diese Arbeit? — lautet die Antwort für mindestens 80 % der Arbeit: Nein. Du brauchst einen VPS, Docker, Tailscale und etwa zwei Stunden.\n\nDas Terminal wartet.\n\n## Lass uns zusammenarbeiten\n\nMöchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.\n\n* Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD\n* Portfolio: mejba.me\n* Ramlit Limited (Enterprise-Lösungen): ramlit.com\n* ColorPark (Design & Branding): colorpark.io\n* xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io"