Multica self-hosten op een Hetzner-VPS: mijn volledige buildlog
De vraag achter deze post: als ik coding agents als teamgenoten ga inzetten, heb ik daar dan echt de cloud van Anthropic voor nodig?
Eerst een korte opmerking over de naam voordat we verdergaan. De videosamenvatting waarmee ik werkte noemde deze tool Multimodal. Het daadwerkelijke project op GitHub, het project dat ik heb geïnstalleerd, heet Multica: de repo is multica-ai/multica, de CLI-binary is multica en de daemon is multica daemon. Ik noem het in de rest van deze post bij zijn echte naam, zodat de commando's in deze log te kopiëren en plakken zijn in plaats van wensdenken.
Multica presenteert zich als een open-source platform voor managed agents: een laag die terminal-coding agents zoals Claude Code, Codex CLI en OpenCode verandert in samenwerkende teamgenoten aan wie je issues kunt toewijzen, met wie je direct kunt chatten en voor wie je terugkerend werk kunt inplannen. Het geheel is zelf te hosten. Het geheel is Docker. En het geheel kan op een kleine VPS draaien, met één logindetail dat je moet regelen.
Dit is de buildlog. De Hetzner-machine die ik koos, het opstarten met Docker Compose, de exacte aanpassing in het env-bestand waarmee ik voorbij het kapotte loginscherm kwam, de aanroep van multica daemon, de eerste agent die ik aanmaakte, de Autopilot-cron die ik opzette ter vervanging van een Claude Routine, en de eerlijke vergelijking aan het eind. Als iets op mijn machine zich anders gedroeg dan de docs beloofden, meld ik dat in plaats van te doen alsof het pad soepel verliep.
Laat ik beginnen met waarom ik stopte met scrollen en dit echt heb geprobeerd.
Waarom ik de rekening van Managed Agents niet meer vertrouwde
Claude Managed Agents werd op 8 april 2026 gelanceerd in publieke bèta. Twee weken later had ik vier routines die volgens een schema afgingen, één agent die reageerde op webhooks, en een factuurregel voor sessie-uren die zich heel anders gedroeg dan een gewone API-afrekening. Managed Agents rekent af op twee dimensies, standaard tokentarieven plus $ 0,08 per sessie-uur actieve runtime, en die tweede is degene die je verrast. Tokens voor Sonnet 4.6 kosten $ 3 input / $ 15 output per miljoen. Dat is voorspelbaar. Een sessie die op "running" blijft staan terwijl een agent wacht op een trage git clone: dat is een meter waarvan ik niet kan zien dat hij loopt.
Niets hiervan is een schandaal. Anthropic is transparant over de prijzen, en de runtimemeter pauzeert wanneer de sessie niet actief werk doet. Het probleem is niet eerlijkheid. Het probleem is controle. Ik wilde tot op de watt weten wat mijn agents kostten en deden. Ik wilde er één zes uur kunnen laten draaien zonder naar een dashboard te kijken. Ik wilde hem op een privérepo kunnen richten zonder een managed cloud daar toegang toe te geven. En ik wilde het model eronder kunnen wisselen (Claude, GLM-4.6, wat het stealth-model van de week van Open Code Zen ook is) zonder van abonnement te veranderen.
Multica lost alle vier daarvan op. Je draait het platform op je eigen hardware. Je installeert de CLI's van de coding agents op die hardware. Je geeft Multica de API-keys. Het wijst je issues toe aan de agents. Jij kijkt hoe het werkt. Je rekening is wat het onderliggende model kost plus de VPS.
Dat is in elk geval het verkoopverhaal. Of het standhoudt, hangt ervan af of je het echt aan de praat krijgt.
Waarom Hetzner, en welke machine ik koos
Ik heb dit soort workloads eerder op goedkopere hosts geprobeerd. De droplet van $ 4/maand die ik vorig najaar voor een Claude Code-daemon gebruikte, had niet genoeg RAM om drie Docker-containers te draaien plus een agent die een Node-workspace opstart. De standaardstack van Multica bestaat uit drie containers (een Go-backend, een Next.js/TypeScript-frontend en een Postgres-instantie voor sessieopslag), en wanneer een agent een taak krijgt, start de daemon het CLI-proces op diezelfde machine. De vraag over de dimensionering is dus niet "kan hij de stack opstarten" maar "kan hij de stack opstarten en ook Claude Code een React-app laten bouwen zonder dat er iets door de OOM-killer wordt afgeschoten".
Ik kwam om twee redenen bij Hetzner uit. Ten eerste is de verhouding tussen prijs en specificaties in 2026 nog steeds absurd. Ten tweede draaien de nieuwe CX-plan-machines met gedeelde vCPU op Ampere Altra ARM-silicium en de grote Intel/AMD-broers aan de x86-kant, dus kon ik kiezen wat het beste bij mijn toolchain paste. Op het moment van schrijven stond de CX22 vermeld voor € 4,49/maand (2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB verkeer), met de CPX21 op dedicated AMD als de volgende stap omhoog. Controleer de actuele prijslijst van Hetzner voordat je een budget maakt. Ik begon op de CX22, alleen om te zien of de goedkoopste realistische machine de stack echt aankon.
Kort antwoord: ja, voor één of twee agents tegelijk. Als je van plan bent vier Claude Code-sessies parallel te draaien, ga dan naar de CPX21 of hoger.
Voordat ik iets deployde, deed ik het ding dat ik altijd vergeet en dan betreur: ik heb SSH dichtgetimmerd. Alleen authenticatie met keys, root-login met wachtwoord uitgeschakeld, ufw die alleen 22, 80, 443 toestaat plus de poort die de frontend van Multica zou gaan openzetten. Ik installeerde Docker Engine ook met het officiële convenience-script, niet de versie uit de Ubuntu-repo, omdat het compose-bestand van Multica nieuwere healthcheck-syntax gebruikt.
Toen de machine schoon was, heb ik de repo gekloond.
Het opstarten: drie containers, één env-bestand, één kapotte login
De README van Multica geeft je twee installatiepaden. Het eerste is het bedoelde: installeer de CLI lokaal, richt hem op de gehoste UI van Multica Cloud en laat hen de backend afhandelen. Dat is het pijnloze pad. Het is ook niet het pad waarvoor ik hier was.
Het tweede is volledige self-hosting. Je kloont de repo, past een env-bestand aan en start de hele stack op met Docker Compose. (De huidige README documenteert voor dit pad een installatiescript plus multica setup self-host; de handmatige stappen hieronder dateren van daarvoor.)
# On the Hetzner box, as a non-root sudo user
git clone https://github.com/multica-ai/multica.git
cd multica
# Copy the example env file to a real one
cp .env.example .env
# Inspect what you're about to run
docker compose config
# First run — pull images and bring it up
docker compose up -d
De drie services die opstarten zijn, in de volgorde van het compose-bestand: db (PostgreSQL 17), backend (de Go-API, standaard op 8080) en frontend (de Next.js-UI, op 3000). De healthchecks koppelen ze correct aan elkaar, zodat de frontend wacht op de backend, die wacht op Postgres.
Na de eerste keer opstarten toonde docker compose ps alle drie als healthy. Ik opende de frontend in een browser op http://<vps-ip>:3000 en kreeg een loginscherm dat om mijn e-mailadres vroeg.
Dit is de muur waar de videosamenvatting voor waarschuwde. De login van Multica mailt een verificatiecode van zes cijfers via Resend. Op een zelfgehoste machine zonder geconfigureerde RESEND_API_KEY komt die e-mail nooit aan.
De self-hosting-gids geeft drie manieren om erdoor te komen. Configureer RESEND_API_KEY zodat er echte codes worden gemaild; dat is het aanbevolen pad. Of laat hem leeg en kopieer de gegenereerde code uit de logs van de backendcontainer. Of stel, alleen voor privétests, een vaste code in .env in:
# In /opt/multica/.env on the VPS
APP_ENV=development
MULTICA_DEV_VERIFICATION_CODE=888888
MULTICA_DEV_VERIFICATION_CODE stelt één vaste code van zes cijfers in die de backend voor elk e-mailadres accepteert. Hij wordt genegeerd wanneer APP_ENV=production, en de Docker-self-hoststack staat standaard op APP_ENV=production.
Na het opslaan van het bestand:
docker compose down
docker compose up -d
Na de herstart log je in met een e-mailadres plus de vaste code.
Dit is het waard om expliciet te zeggen: APP_ENV=development is geen authenticatiemodus voor productie. Het is prima wanneer de VPS op een Tailscale-mesh zit en er geen publiek verkeer bij poort 3000 kan komen. Het is niet prima wanneer de frontend openstaat naar het open internet. Ik kom daarop terug in de sectie over security, omdat het het enige is waarvan ik iedereen die deze setup doet zou zeggen: zorg dat je dit goed doet.
De daemon en de runtimes registreren
Met de UI draaiend en een admin-account aangemaakt, is de volgende stap het aansluiten van de eigenlijke werklaag. De architectuur van Multica is helder zodra je hem doorziet: de UI is waar je agents en issues definieert, en een apart daemon-proces is wat het werk daadwerkelijk oppakt en de CLI's van de coding agents draait.
De daemon staat in dezelfde repo. Op de VPS:
# Install the multica CLI (Go binary — the repo ships one)
cd /opt/multica
sudo cp ./bin/multica /usr/local/bin/
multica --version
# Authenticate the daemon against the UI
# You copy a token from the UI's Runtimes page and paste it here
multica auth login --server http://localhost:8080 --token <API_TOKEN>
# Start the daemon as a long-running process
multica daemon
Bij de eerste start scant de daemon $PATH en detecteert automatisch welke agent-CLI's op de machine geïnstalleerd zijn. De ondersteunde lijst toen dit geschreven werd was claude, codex, openclaw, opencode, hermes, gemini, pi en cursor-agent; de README vermeldt nu 29 agent-CLI's. Op deze machine installeerde ik er twee: Claude Code (via de officiële npm-installatie) en OpenCode (via de standalone installer). Na het starten van de daemon verschenen beide runtimes in het Runtimes-paneel van de UI als "connected".
Wat ik niet had verwacht, en wat deze architectuur veel interessanter maakt dan ik op basis van de video had aangenomen, is dat je met het API-tokenmodel de daemon op meerdere machines tegen één UI kunt draaien. Je start een tweede VPS, installeert daar Claude Code, genereert een tweede token in de UI, logt de tweede daemon met dat token in, en ineens heb je twee runtimes waarover de takenwachtrij kan verdelen. Voor mij blijft dat theoretisch, want ik heb maar die ene Hetzner-machine, maar als je een klein team hebt, is het de weg naar een echte vloot agents over meerdere machines zonder iemands cloud aan te raken.
Eén valkuil: als het daemonproces doodgaat, gaat de runtime offline en blijven taken die eraan zijn toegewezen in de wachtrij staan. Ik heb hem in een kleine systemd-unit verpakt, zodat hij herstart na een crash en na een reboot:
# /etc/systemd/system/multica-daemon.service
[Unit]
Description=Multica agent daemon
After=docker.service
Requires=docker.service
[Service]
Type=simple
User=mejba
WorkingDirectory=/home/mejba
ExecStart=/usr/local/bin/multica daemon
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now multica-daemon
sudo systemctl status multica-daemon
Daarmee overleeft de daemon reboots en komt hij vanzelf terug als hij crasht. Ik heb niet hoeven debuggen waarom hij crashte (dat is hij niet, in de week dat hij nu draait), maar de automatische herstart is er.
Mijn eerste agent: een retrievalbot voor mijn eigen notities
Het voorbeeld in de video-walkthrough was een retrievalagent voor medische informatie die uit een privé-GitHub-repo putte om vragen te beantwoorden. Ik bouwde iets dat structureel identiek is voor mijn eigen doeleinden: een agent die toegang heeft tot mijn privérepo met Obsidian-notities en daaruit vragen beantwoordt zonder dat ik zelf door Markdown-bestanden hoef te graven. Het patroon is hetzelfde; de inhoud is van mij.
In de UI van Multica kost het aanmaken van een agent twee velden: een naam en een system prompt. Optioneel kun je skills koppelen (kleine, afgebakende tools die de agent kan aanroepen), maar voor mijn eerste run hield ik het bij alleen de prompt.
Dit is de system prompt die ik gebruikte, ontdaan van de repo-specifieke stukken:
You are NotesBot, a focused retrieval agent working against a cloned
copy of my private notes repository located at /workspaces/notes.
When I assign you an issue, treat the issue body as a question. Your
job is to:
1. Grep the repo for the most relevant notes (use ripgrep, not find).
2. Read the top 3-5 candidate files in full before answering.
3. Respond with: a direct answer, the filenames you used as sources
(as relative paths from the repo root), and a "confidence" line
that is one of: high / medium / low.
4. If you can't find anything relevant, say so explicitly and suggest
three adjacent queries I might try instead.
Never modify files. Never create new notes. You are read-only.
Use opencode with the zen big-pickle model unless told otherwise.
Die laatste regel is bewust. Met Multica configureer je per agent welke CLI en welke flags worden gebruikt. Voor NotesBot richtte ik hem op OpenCode met het model zen/big-pickle, de codenaam van OpenCode Zen voor wat de community heeft geïdentificeerd als GLM-4.6: 200K context, gratis tijdens de huidige periode, en echt bekwaam in retrievaltaken. Het equivalente CLI-commando dat de daemon onder de motorkap draait, komt neer op iets als:
opencode run --model zen/big-pickle --non-interactive \
--workspace /workspaces/notes-<task-id> \
--prompt-file /tmp/multica-<task-id>-prompt.txt
Dat commando typ je niet zelf. De daemon stelt het samen uit de config van de agent plus de body van het issue. Maar het zien van de vorm van wat er wordt uitgevoerd, is wat het systeem voor mij liet landen: Multica is geen nieuwe runtime, het is een orchestrator die runtimes aanroept die je al weet te configureren.
Ik maakte mijn eerste issue aan: "Welke van mijn notities behandelen het onderscheid tussen 'open loops' en 'pattern interrupts' in de structuur van een artikel?" Prioriteit: medium. Agent: NotesBot. Deadline: vandaag.
De agent pakte het kort nadat ik op toewijzen klikte op. De daemonlogs toonden de kloon van de workspace, de ripgrep-ronde, het lezen van de bestanden en het genereren van het antwoord. NotesBot plaatste daarna zijn antwoord als reactie op het issue, inclusief drie bronbestandsnamen en een confidence-vlag "high". Ik klikte op de drie bestandsnamen, bevestigde dat het de juiste notities waren en verplaatste de taak naar Done.
Dat was het moment waarop ik begreep waarom de presentator van de walkthrough zei dat hij direct chatten met agents verkiest boven het Kanban-bord. Multica heeft een interface voor directe chat (je kunt elke agent openen en er conversationeel mee praten zonder via een issue te gaan) en voor snelle retrievalvragen is die interface beter dan het ritueel van taakkaarten. Voor langer werk is het takensysteem echter waar het platform zijn waarde bewijst.
Autopilot opzetten: de open-source tegenhanger van Claude Routines
Hier wordt de vergelijking met Claude Managed Agents interessant. Met Claude Routines (inmiddels hernoemd tot scheduled tasks) draai je een ingeplande prompt op de infrastructuur van Anthropic volgens een vooraf ingesteld ritme (elk uur, dagelijks, op werkdagen, wekelijks) of bij een webhook, of bij een GitHub-event. Het is echt nuttig.
Het antwoord van Multica is Autopilot. Het is een planner voor terugkerende taken die direct in het issuesysteem is ingebouwd. Je kiest een agent, schrijft een prompt, stelt een ritme in, en telkens wanneer het ritme afgaat, maakt Multica een nieuw issue aan dat aan die agent is toegewezen, met de prompt als body.
De feature die ik als eerste opzette: een dagelijkse taak om 9 uur 's ochtends Londense tijd die NotesBot vraagt elke notitie van de afgelopen 24 uur naar boven te halen waarin een toolnaam voorkomt waarover ik nog niet heb geschreven. Het doel is om me druppelsgewijs onderwerpkandidaten voor toekomstige posts te geven.
In de UI neemt Autopilot vier velden: agent, prompt, ritme (cron-stijl, met presets voor elk uur / dagelijks / werkdagen / wekelijks) en tijdzone. Mijn config:
- Agent: NotesBot
- 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. - Ritme:
0 9 * * *(dagelijks om 9 uur 's ochtends) - Tijdzone:
Europe/London
Hij gaat elke ochtend af. Het resulterende issue komt op het bord onder "Open", de daemon pakt het op, en kort daarna staat het antwoord in de reacties van het issue. Als het antwoord nuttig is, werp ik er een blik op. Zo niet, dan markeer ik het issue als Done en ga ik verder.
Het is goed om eerlijk te zijn over wat Autopilot niet heeft, want hier wint Claude Routines nog steeds voor bepaalde use cases. Toen dit geschreven werd, ondersteunde Autopilot alleen ingeplande triggers. De docs van Multica vermelden nu twee triggertypes voor een autopilot: een schema of een webhook. Dat is nog steeds niet hetzelfde als het GitHub-event-aanbod van Routines.
De andere beperking die je moet kennen voordat je op Autopilot bouwt: agents verplaatsen taken door hun bordstatussen tot In Review, maar niet helemaal tot Done. De mens moet afronden. Agents zetten statussen ook niet terug: als een taak al In Review staat, duwt een nieuwe run hem niet terug naar Open. Dat is een bewuste ontwerpkeuze om de mens betrokken te houden bij het eindoordeel, en die bevalt me, maar het betekent dat "volledig autonoom, geen mens raakt ooit het bord aan" geen modus is die dit systeem standaard ondersteunt.
Eerlijke vergelijking: Multica self-host vs Claude Managed Agents
Nu de vergelijking naast elkaar. Ik wil de open-source kant niet overdrijven. Beide hebben echte sterke punten; beide hebben echte gaten.
Kosten: Dit is waar self-hosting het duidelijkst wint. Mijn Multica-setup is een VPS van € 4,49/maand plus wat de API van het onderliggende model kost wanneer agents draaien. Als een agent Claude Sonnet 4.6 via de API gebruikt, is dat $ 3/$ 15 per miljoen tokens, hetzelfde tarief dat Managed Agents zou rekenen, maar er loopt geen meter van $ 0,08/sessie-uur bovenop. Voor een workflow waarin een agent 90 minuten aan één lange klus besteedt, is dat een concrete besparing van $ 0,12 bovenop wat ik sowieso voor tokens had betaald.
Controle: Ook een duidelijke winst voor self-hosting. Ik kan de daemon pauzeren, de Postgres-container openen en de sessietabel inspecteren, de daemonlogs regel voor regel lezen en ingrijpen bij een vastgelopen taak. Ik kan de agent op een privé-GitHub-repo richten zonder een derde partij toegang tot de code te geven. De machine, de data en het netwerkpad zijn van mij.
Triggermogelijkheden: Hier wint Claude Managed Agents nog steeds. Routines ondersteunen standaard triggers via schema, webhook en GitHub. Multica Autopilot ondersteunde toen dit geschreven werd alleen een schema; de docs vermelden nu schema en webhook. Als je workflow afhangt van "afgaan bij het openen van een PR", heeft Claude dat native.
Afwerking van de UX: De interface van Claude is gepolijster. De Claude Code-integratie, het Routines-paneel in de desktopapp, de managed dashboards: ze zijn verder in afwerking. De UI van Multica is functioneel en strak, maar voelt vroeger aan. Je merkt dat je bij de tweede generatie gebruikers hoort in plaats van de honderdduizendste.
Meerdere agents / meerdere machines: Self-hosting wint hier door het ontwerp. Richt de daemons van meerdere VPS'en op één Multica-UI met verschillende API-tokens, en je hebt een echte vloot. Claude Managed Agents draait alles in de cloud van Anthropic, wat prima is als je dat wilt, en geen optie is als je dat niet wilt.
Betrouwbaarheid onder druk: Ik kan niet beweren dat de daemon van Multica al maanden productie heeft overleefd. Ik heb hem een week op één machine gedraaid, en hij is stabiel geweest. De runtime van Anthropic is de runtime van Anthropic; zij zullen een uptime hebben die ik op een CX22 niet kan evenaren.
Waar ik elk daadwerkelijk zou gebruiken: Ik zou Claude Managed Agents houden voor de workflows waarin triggeren op GitHub-events het hele punt is: "Claude reviewt elke PR op deze repo" past daar beter. Ik zou Multica self-host gebruiken voor alles waarbij controle, kosten of toegang tot privédata de doorslag geven: mijn notities, mijn klantcode, mijn langlopende retrievalwerk.
Security: het ene ding dat je goed moet doen
Self-hosting betekent dat het aanvalsoppervlak van jou is. Dit is geen leuk-om-te-hebben-sectie. Als je hem overslaat, heb je een loginpagina op het open internet gebouwd met een vaste dev-verificatiecode ingesteld, een configuratie waarin iedereen die een e-mailadres kent kan inloggen. Dat is een slechtere securitypositie dan helemaal geen authenticatie, omdat het eruitziet alsof er authenticatie is.
Twee paden die echt werken.
Pad één: Tailscale mesh-VPN. Dit is wat ik gebruik. Installeer Tailscale op de Hetzner-machine (curl -fsSL https://tailscale.com/install.sh | sh en dan sudo tailscale up), installeer het op je laptop en telefoon, en configureer de firewall van de VPS zo dat poorten 3000, 8080 en SSH alleen bereikbaar zijn op de Tailscale-interface (tailscale0), niet op de publieke ethernet. Tailscale geeft elk apparaat in je "tailnet" een stabiel 100.x.x.x-adres, gebruikt end-to-end-encryptie met WireGuard en komt door NAT heen zonder port forwarding. De frontend op http://100.x.y.z:3000 is alleen bereikbaar vanaf je eigen apparaten. Niemand anders op het publieke internet kan poort 3000 überhaupt zien.
Als je verder wilt gaan, gebruik dan Headscale, een zelfgehoste implementatie van de controleserver van Tailscale, zodat zelfs de coördinatie van je mesh op je eigen infrastructuur draait. Voor een eenmanssetup is dat overkill, maar het bestaat.
Pad twee: volledig lokaal, geen internet. Multica draait op localhost. Als je Docker en de daemon installeert op een laptop of een thuisserver die nooit het publieke internet raakt, is de hele stack zo lokaal als je hardware. Je verliest het gemak van "ik kan erbij vanaf mijn telefoon". Je wint een dreigingsoppervlak dat letterlijk je fysieke machine is.
Welk pad je ook kiest: houd de Docker-images actueel (regelmatig docker compose pull && docker compose up -d), houd de kernel van de host gepatcht, en onthoud dat APP_ENV=development moet worden behandeld als een vlag voor uitsluitend privénetwerken. Als je de frontend ooit op een echt publieke URL moet openzetten, bijvoorbeeld omdat je wilt dat teamgenoten zonder Tailscale erbij kunnen, zet die vlag dan terug, configureer een echte authenticatiebackend volgens de self-hosting-docs van Multica, en zet er een reverse proxy met TLS voor.
Blootstelling van een kale VPS is de zorg, omdat Hetzner je, zoals elke publieke cloud, een IP geeft dat binnen enkele minuten na toewijzing wordt gescand. Poort 3000 die HTTP beantwoordt tijdens een scannerronde is een baken. Een authenticatiescherm in dev-modus dat het curl-verzoek van die scanner beantwoordt, is erger dan een gesloten poort.
Wat ik hierna zou bouwen
Na een week zijn de twee richtingen die ik in de gaten houd: (1) mijn CI koppelen aan de API van Multica voor het aanmaken van issues, zodat falende builds automatisch een debug-issue starten dat aan een Claude Code-runtime is toegewezen, en (2) een daemon op een tweede VPS draaien die gewijd is aan een "reviewer"-agent die een ander model gebruikt dan de "builder", zodat ik een second opinion krijg op PR's van agents voordat ik ze merge. Geen van beide heeft nieuwe features van Multica nodig: de API en het daemonmodel over meerdere machines ondersteunen beide al.
Wat ik nog niet doe, en waarschijnlijk pas zal doen als Multica GitHub-event-triggers in Autopilot uitbrengt, is mijn GitHub-event-routines weghalen bij Claude Managed Agents. Voor die use case wint het triggeraanbod. Ik houd beide platforms, betaal Anthropic voor waar zij het best in zijn, en draai de rest op € 4,49 aan Hetzner.
Het verschil met self-hosting is dat ik, wanneer een agent twee uur aan een taak werkt, een terminal kan openen, via SSH op mijn eigen machine kan inloggen, de daemonlog kan tailen en hem kan zien denken. Dat is € 4,49 per maand waard. Misschien meer.
Als je naar je eigen rekening voor managed agents hebt zitten staren en jezelf dezelfde vraag hebt gesteld (heb ik deze cloud echt nodig voor dit werk?), dan is het antwoord, voor veel van het werk, nee. Je hebt een VPS, Docker en Tailscale nodig. De rest is gedocumenteerd.
De terminal wacht.
Of Multica self-hosten de moeite waard is
Multica self-hosten op een Hetzner-VPS gaf me een open-source alternatief voor Claude Managed Agents dat op mijn voorwaarden draait: mijn data, mijn keys, mijn uptime. Die controle is de frictie van de setup waard als privacy of kosten voor jou zwaarder wegen dan het gemak van een managed dienst.
Het vraagt meer onderhoud dan een gehoste dienst, dus begin eraan met open ogen. Begin op een goedkope droplet die je opnieuw kunt opbouwen, en leun er pas op zodra hij stabiel is.
Als je een zelfgehost agentplatform wilt laten opzetten en harden, is dat iets wat ik via Ramlit doe, en ik documenteerde een vergelijkbare VPS-build in mijn Hermes-deploymentlog en mijn build van de OpenClaw-assistent.
