Multica autoalojado en un VPS de Hetzner: mi bitácora completa
La pregunta detrás de este post: si voy a usar agentes de programación como compañeros de equipo, ¿de verdad necesito la nube de Anthropic para hacerlo?
Una nota rápida sobre el nombre antes de seguir. El resumen del vídeo con el que trabajaba llamaba a esta herramienta Multimodal. El proyecto real en GitHub, el que instalé, se llama Multica: el repo es multica-ai/multica, el binario de la CLI es multica y el daemon es multica daemon. Lo llamo por su nombre real en el resto de este post para que los comandos de esta bitácora se puedan copiar y pegar en lugar de ser una aspiración.
Multica se presenta como una plataforma open source de agentes gestionados: una capa que convierte agentes de programación de terminal como Claude Code, Codex CLI y OpenCode en compañeros de equipo colaborativos a los que puedes asignar issues, con los que puedes chatear directamente y para los que puedes programar trabajo recurrente. Todo se puede autoalojar. Todo es Docker. Y todo puede ejecutarse en un VPS pequeño, con un detalle del login que hay que resolver.
Esta es la bitácora. El servidor de Hetzner que elegí, el arranque con Docker Compose, la edición exacta del archivo env que me permitió pasar la pantalla de login rota, la invocación de multica daemon, el primer agente que creé, el cron de Autopilot que configuré para sustituir una Claude Routine y la comparación honesta del final. Si algo en mi máquina se comportó de forma distinta a lo que prometía la documentación, lo señalo en lugar de fingir que el camino fue sencillo.
Empiezo por el motivo por el que dejé de hacer scroll y lo probé de verdad.
Por qué dejé de fiarme de la factura de los agentes gestionados
Claude Managed Agents se lanzó en beta pública el 8 de abril de 2026. Dos semanas después tenía cuatro routines ejecutándose según una programación, un agente que se ejecutaba en respuesta a webhooks y una línea de facturación por horas de sesión que se comportaba de forma muy distinta a un cargo de API típico. Managed Agents factura en dos dimensiones — las tarifas estándar por token más $0,08 por hora de sesión de tiempo de ejecución activo — y la segunda es la que te pilla. Los tokens de Sonnet 4.6 cuestan $3 de entrada / $15 de salida por millón. Eso es predecible. Una sesión que se queda en estado «running» mientras un agente espera a un git clone lento: ese es un contador que no veo avanzar.
Nada de esto es un escándalo. Anthropic es transparente con los precios y el contador de tiempo de ejecución se pausa cuando la sesión no está trabajando activamente. El problema no es la justicia. El problema es el control. Quería saber, hasta el último vatio, cuánto me costaban mis agentes y qué hacían. Quería poder tener uno ejecutándose durante seis horas sin mirar un dashboard. Quería apuntarlo a un repo privado sin dar acceso a él a una nube gestionada. Y quería poder cambiar el modelo de debajo — Claude, GLM-4.6, el modelo sigiloso de la semana de Open Code Zen — sin cambiar de plan.
Multica resuelve las cuatro cosas. Ejecutas la plataforma en tu propio hardware. Instalas las CLI de los agentes de programación en ese hardware. Le das a Multica las API keys. Asigna tus issues a los agentes. Tú lo ves trabajar. Tu factura es lo que cueste el modelo subyacente más el VPS.
Al menos ese es el argumento. Que se sostenga depende de si de verdad consigues ponerlo en marcha.
Por qué Hetzner y qué servidor elegí
Ya había probado antes a ejecutar este tipo de carga de trabajo en hosts más baratos. El droplet de $4/mes que usé para un daemon de Claude Code el otoño pasado no tenía la RAM para ejecutar tres contenedores Docker más un agente levantando un workspace de Node. El stack por defecto de Multica son tres contenedores — un backend en Go, un frontend en Next.js/TypeScript y una instancia de Postgres para guardar las sesiones —, y cuando se asigna una tarea a un agente, el daemon lanza el proceso de la CLI dentro de esa misma máquina. Así que la pregunta de dimensionamiento no es «¿puede arrancar el stack?», sino «¿puede arrancar el stack y además ejecutar Claude Code construyendo una app de React sin que el OOM killer mate algo?».
Me quedé con Hetzner por dos razones. Primero, la relación precio-especificaciones en 2026 sigue siendo absurda. Segundo, los nuevos servidores del plan CX con vCPU compartida funcionan sobre silicio ARM Ampere Altra y sus hermanos grandes de Intel/AMD en el lado x86, así que podía elegir el que mejor encajara con mi toolchain. En el momento de escribir esto, el CX22 figuraba a €4,49/mes — 2 vCPU, 4 GB de RAM, 40 GB NVMe, 20 TB de tráfico —, con el CPX21 sobre AMD dedicado como el siguiente nivel. Consulta la lista de precios actual de Hetzner antes de hacer el presupuesto. Empecé con el CX22 solo para ver si el servidor realista más barato podía de verdad aguantar el stack.
Respuesta corta: sí, para uno o dos agentes ejecutándose a la vez. Si piensas ejecutar cuatro sesiones de Claude Code en paralelo, pasa al CPX21 o superior.
Antes de desplegar nada, hice lo que siempre olvido y luego lamento: bloqueé SSH. Autenticación solo con clave, login de root con contraseña deshabilitado, ufw permitiendo solo 22, 80, 443 y el puerto que fuera a exponer el frontend de Multica. También instalé Docker Engine con el script de conveniencia oficial, no con la versión del repo de Ubuntu, porque el archivo compose de Multica usa una sintaxis de healthcheck más reciente.
Con el servidor limpio, cloné el repo.
El arranque: tres contenedores, un archivo env, un login roto
El README de Multica te da dos caminos de instalación. El primero es el previsto: instalar la CLI en local, apuntarla a la UI alojada de Multica Cloud y dejar que ellos se ocupen del backend. Ese es el camino sin dolor. Tampoco es el camino por el que yo estaba aquí.
El segundo es el autoalojamiento completo. Clonas el repo, personalizas un archivo env y levantas todo el stack con Docker Compose. (El README actual documenta un script de instalación más multica setup self-host para este camino; los pasos manuales de abajo son anteriores a eso.)
# 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
Los tres servicios que se levantan son, en el orden del archivo compose: db (PostgreSQL 17), backend (la API en Go, expuesta en el 8080 por defecto) y frontend (la UI en Next.js, expuesta en el 3000). Los healthchecks los encadenan correctamente, de modo que el frontend espera al backend, que a su vez espera a Postgres.
Tras el primer arranque, docker compose ps mostraba los tres en estado healthy. Abrí el frontend en un navegador en http://<vps-ip>:3000 y me encontré una pantalla de login que pedía mi email.
Este es el muro del que avisaba el resumen del vídeo. El login de Multica envía por email un código de verificación de seis dígitos a través de Resend. En un servidor autoalojado sin RESEND_API_KEY configurada, ese email nunca llega.
La guía de autoalojamiento da tres formas de superarlo. Configurar RESEND_API_KEY para que los códigos reales se envíen por email, que es el camino recomendado. O dejarla sin configurar y copiar el código generado de los logs del contenedor del backend. O, solo para pruebas privadas, fijar un código en .env:
# In /opt/multica/.env on the VPS
APP_ENV=development
MULTICA_DEV_VERIFICATION_CODE=888888
MULTICA_DEV_VERIFICATION_CODE fija un único código de seis dígitos que el backend acepta para cualquier dirección de email. Se ignora cuando APP_ENV=production, y el stack de autoalojamiento con Docker usa APP_ENV=production por defecto.
Después de guardar el archivo:
docker compose down
docker compose up -d
Tras el reinicio, una dirección de email más el código fijo te permiten iniciar sesión.
Vale la pena decirlo explícitamente: APP_ENV=development no es un modo de autenticación para producción. Está bien cuando el VPS está en una malla de Tailscale y ningún tráfico público puede llegar al puerto 3000. No está bien cuando el frontend está expuesto a internet abierto. Volveré a esto en la sección de seguridad, porque es lo único que le diría a cualquiera que haga esta configuración que tiene que hacer bien.
Registrar el daemon y los runtimes
Con la UI funcionando y una cuenta de administrador creada, el siguiente paso es conectar la capa de trabajo real. La arquitectura de Multica es limpia una vez que la ves: la UI es donde defines agentes e issues, y un proceso daemon separado es el que realmente recoge el trabajo y ejecuta las CLI de los agentes de programación.
El daemon vive en el mismo repo. En el 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
En el primer arranque, el daemon recorre $PATH y detecta automáticamente qué CLI de agentes están instaladas en la máquina. La lista compatible cuando se escribió esto era claude, codex, openclaw, opencode, hermes, gemini, pi y cursor-agent; el README ahora enumera 29 CLI de agentes. En este servidor instalé dos: Claude Code (con la instalación oficial por npm) y OpenCode (con su instalador independiente). Tras arrancar el daemon, ambos runtimes aparecieron en el panel Runtimes de la UI como «connected».
Lo que no esperaba, y lo que hace esta arquitectura mucho más interesante de lo que había supuesto por el vídeo, es que el modelo de API tokens te permite ejecutar el daemon en varias máquinas contra una sola UI. Levantas un segundo VPS, instalas Claude Code allí, generas un segundo token en la UI, inicias sesión con ese token en el segundo daemon y de repente tienes dos runtimes entre los que la cola de tareas puede repartir el trabajo. Para mí eso sigue siendo teórico — solo tengo el servidor de Hetzner —, pero si llevas un equipo pequeño, es el camino hacia una flota real de agentes en varias máquinas sin tocar la nube de nadie.
Un detalle a tener en cuenta: si el proceso del daemon muere, el runtime se desconecta y las tareas asignadas a él se quedan esperando en la cola. Lo envolví en una pequeña unidad de systemd para que se reinicie tras un fallo y tras un reinicio del sistema:
# /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
Con eso en su sitio, el daemon sobrevive a los reinicios y vuelve solo si se cae. No he tenido que depurar por qué se cayó — no lo ha hecho en la semana que lleva funcionando —, pero el reinicio automático está ahí.
Mi primer agente: un bot de recuperación para mis propias notas
El ejemplo del tutorial en vídeo era un agente de recuperación de información médica que tiraba de un repo privado de GitHub para responder preguntas. Yo construí algo estructuralmente idéntico para mis propios fines: un agente con acceso a mi repo privado de notas de Obsidian que responde preguntas a partir de él sin que yo tenga que rebuscar entre archivos Markdown. El patrón es el mismo; el contenido es mío.
En la UI de Multica, crear un agente requiere dos campos: un nombre y un system prompt. Opcionalmente puedes adjuntar skills — pequeñas herramientas acotadas que el agente puede invocar —, pero en mi primera ejecución me limité al prompt.
Este es el system prompt que usé, sin las partes específicas del repo:
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.
Esa última línea es intencionada. Multica te permite configurar, por agente, qué CLI y qué flags se usan. Para NotesBot lo apunté a OpenCode con el modelo zen/big-pickle, que es el nombre en clave de OpenCode Zen para lo que la comunidad ha identificado como GLM-4.6: 200K de contexto, gratis durante su ventana actual y realmente competente en tareas de recuperación. La CLI equivalente que el daemon ejecuta por debajo se resuelve en algo como:
opencode run --model zen/big-pickle --non-interactive \
--workspace /workspaces/notes-<task-id> \
--prompt-file /tmp/multica-<task-id>-prompt.txt
Tú no tecleas ese comando. El daemon lo compone a partir de la configuración del agente más el cuerpo del issue. Pero ver la forma de lo que se ejecuta fue lo que hizo que el sistema me encajara: Multica no es un runtime nuevo, es un orquestador que delega en runtimes que ya sabes configurar.
Creé mi primer issue: «¿Cuáles de mis notas tratan la diferencia entre 'open loops' y 'pattern interrupts' en la estructura de un artículo?» Prioridad: media. Agente: NotesBot. Vencimiento: hoy.
El agente lo recogió poco después de que hiciera clic en asignar. Los logs del daemon mostraban la clonación del workspace, la pasada de ripgrep, las lecturas de archivos y la generación de la respuesta. Después NotesBot publicó su respuesta como comentario en el issue, incluyendo tres nombres de archivo como fuentes y una marca de confianza «high». Hice clic en los tres nombres de archivo, confirmé que eran las notas correctas y moví la tarea a Done.
Ese fue el momento en que entendí por qué el presentador del tutorial decía que prefiere el chat directo con los agentes antes que el tablero Kanban. Multica tiene una superficie de chat directo — puedes abrir cualquier agente y hablar con él de forma conversacional sin pasar por un issue —, y para preguntas de recuperación rápidas esa superficie es mejor que el ritual de las tarjetas de tareas. Para trabajos más largos, en cambio, el sistema de tareas es donde la plataforma se gana el sueldo.
Configurar Autopilot: el equivalente open source de Claude Routines
Aquí es donde la comparación con Claude Managed Agents se pone interesante. Claude Routines (desde entonces renombrado como scheduled tasks) te permite ejecutar un prompt programado en la infraestructura de Anthropic con una cadencia predefinida — cada hora, a diario, entre semana, semanalmente —, o con un webhook, o con un evento de GitHub. Es realmente útil.
La respuesta de Multica es Autopilot. Es un programador de tareas recurrentes conectado directamente al sistema de issues. Eliges un agente, escribes un prompt, fijas una cadencia y, cada vez que se dispara la cadencia, Multica crea un issue nuevo asignado a ese agente con el prompt como cuerpo.
La función que configuré primero: una tarea diaria a las 9 AM, hora de Londres, que le pide a NotesBot que saque a la luz cualquier nota que haya escrito en las últimas 24 horas y que mencione el nombre de una herramienta sobre la que todavía no he escrito. La intención es irme dando candidatos de temas para futuros posts.
En la UI, Autopilot requiere cuatro campos: agente, prompt, cadencia (estilo cron, con preajustes para hourly / daily / weekdays / weekly) y zona horaria. Mi configuración:
- Agente: 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. - Cadencia:
0 9 * * *(a diario a las 9 AM) - Zona horaria:
Europe/London
Se dispara cada mañana. El issue resultante aparece en el tablero en «Open», el daemon lo recoge y poco después la respuesta está en los comentarios del issue. Si la respuesta es útil, le echo un vistazo. Si no lo es, marco el issue como Done y sigo adelante.
Conviene ser honesto sobre lo que Autopilot no tiene, porque aquí es donde Claude Routines sigue ganando en ciertos casos de uso. Cuando se escribió esto, Autopilot admitía solo disparadores programados. La documentación de Multica ahora enumera dos tipos de disparador para un autopilot: una programación o un webhook. Eso sigue sin ser lo mismo que la superficie de eventos de GitHub de Routines.
La otra limitación que conviene conocer antes de construir sobre Autopilot: los agentes mueven las tareas por los estados del tablero hasta In Review, pero no hasta Done. Es el humano quien debe finalizar. Los agentes tampoco revierten estados: si una tarea ya está en In Review, una nueva ejecución no la devolverá a Open. Es una decisión de diseño deliberada para mantener al humano en el circuito del juicio final, y me gusta, pero significa que «totalmente autónomo, ningún humano toca nunca el tablero» no es un modo que este sistema admita de serie.
Comparación honesta: Multica autoalojado frente a Claude Managed Agents
Ahora, la comparación lado a lado. No quiero vender de más el lado open source. Ambos tienen puntos fuertes reales; ambos tienen carencias reales.
Coste: Aquí es donde el autoalojamiento gana de forma más clara. Mi configuración de Multica es un VPS de €4,49/mes más lo que cueste la API del modelo subyacente cuando los agentes se ejecutan. Si un agente usa Claude Sonnet 4.6 vía API, son $3/$15 por millón de tokens — la misma tarifa que facturaría Managed Agents —, pero no hay un contador de $0,08/hora de sesión corriendo encima. En un flujo de trabajo en el que un agente pasa 90 minutos haciendo un único trabajo largo, eso supone un ahorro concreto de $0,12 además de lo que habría pagado por los tokens de todos modos.
Control: También una victoria clara del autoalojamiento. Puedo pausar el daemon, abrir el contenedor de Postgres e inspeccionar la tabla de sesiones, leer los logs del daemon línea a línea e intervenir en una tarea atascada. Puedo apuntar el agente a un repo privado de GitHub sin dar acceso al código a ningún tercero. Soy dueño del servidor, de los datos y de la ruta de red.
Superficie de disparadores: Aquí es donde Claude Managed Agents sigue ganando. Routines admite disparadores programados, por webhook y de GitHub de serie. Multica Autopilot solo admitía la programación cuando se escribió esto; su documentación ahora enumera programación y webhook. Si tu flujo de trabajo depende de «dispararse al abrir un PR», Claude lo tiene de forma nativa.
Pulido de la UX: La superficie de Claude está más pulida. La integración con Claude Code, el panel de Routines de la app de escritorio, los dashboards gestionados: están más avanzados en ajuste y acabado. La UI de Multica es funcional y limpia, pero se siente más temprana. Se nota que eres la segunda generación de usuarios y no la número cien mil.
Multiagente / multimáquina: El autoalojamiento gana por diseño. Apunta los daemons de varios VPS a una sola UI de Multica con API tokens distintos y tendrás una flota de verdad. Claude Managed Agents lo ejecuta todo en la nube de Anthropic, lo cual está bien si es lo que quieres, y no es una opción si no lo quieres.
Fiabilidad bajo presión: Todavía no puedo afirmar que el daemon de Multica haya sobrevivido meses en producción. Lo he ejecutado durante una semana en un solo servidor y ha sido estable. El runtime de Anthropic es el runtime de Anthropic; tendrán una disponibilidad que yo no puedo igualar en un CX22.
Dónde usaría realmente cada uno: Mantendría Claude Managed Agents para los flujos de trabajo en los que el disparo por eventos de GitHub es lo esencial: «Claude revisa cada PR de este repo» encaja mejor ahí. Usaría Multica autoalojado para todo aquello en lo que el control, el coste o el acceso a datos privados sea el eje dominante: mis notas, el código de mis clientes, mi trabajo de recuperación de larga duración.
Seguridad: lo único que tienes que hacer bien
Autoalojar significa que la superficie de ataque es tuya. Esta no es una sección opcional. Si te la saltas, habrás construido una página de login en internet abierto con un código de verificación de desarrollo fijo, que es una configuración en la que cualquiera que conozca una dirección de email puede iniciar sesión. Es una postura de seguridad peor que no tener autenticación en absoluto, porque parece que la tiene.
Dos caminos que funcionan de verdad.
Camino uno: VPN en malla con Tailscale. Es lo que uso yo. Instala Tailscale en el servidor de Hetzner (curl -fsSL https://tailscale.com/install.sh | sh y después sudo tailscale up), instálalo en tu portátil y en tu teléfono, y reconfigura el firewall del VPS para que los puertos 3000, 8080 y SSH solo sean accesibles desde la interfaz de Tailscale (tailscale0), no desde la ethernet pública. Tailscale da a cada dispositivo de tu «tailnet» una dirección 100.x.x.x estable, usa cifrado de extremo a extremo con WireGuard y atraviesa el NAT sin redirección de puertos. El frontend en http://100.x.y.z:3000 solo es accesible desde tus propios dispositivos. Nadie más en internet público puede ver el puerto 3000 en absoluto.
Si quieres ir más allá, usa Headscale — una implementación autoalojada del servidor de control de Tailscale — para que incluso la coordinación de tu malla esté en tu propia infraestructura. Es excesivo para una configuración de una sola persona, pero existe.
Camino dos: totalmente local, sin internet. Multica se ejecuta en localhost. Si instalas Docker y el daemon en un portátil o un servidor doméstico que nunca toca internet público, todo el stack es tan local como tu hardware. Pierdes la comodidad de «acceder desde el teléfono». Ganas una superficie de amenaza que es literalmente tu máquina física.
Elijas el camino que elijas, mantén las imágenes de Docker al día (docker compose pull && docker compose up -d con regularidad), mantén parcheado el kernel del host y recuerda que APP_ENV=development debe tratarse como un flag solo para redes privadas. Si alguna vez necesitas exponer el frontend en una URL realmente pública — por ejemplo, si quieres que accedan compañeros sin Tailscale —, vuelve a cambiar ese flag, configura un backend de autenticación real según la documentación de autoalojamiento de Multica y pon delante un reverse proxy con TLS.
La exposición directa del VPS es la preocupación porque Hetzner, como cualquier nube pública, te da una IP que se escanea a los pocos minutos de ser asignada. Un puerto 3000 respondiendo HTTP en un barrido de escáner es una baliza. Una pantalla de autenticación en modo desarrollo respondiendo a la petición curl de ese escáner es peor que un puerto cerrado.
Lo que construiría a continuación
Tras una semana, las dos direcciones que estoy vigilando son: (1) conectar mi CI a la API de creación de issues de Multica para que las compilaciones fallidas generen automáticamente un issue de depuración asignado a un runtime de Claude Code, y (2) ejecutar un daemon en un segundo VPS dedicado a un agente «revisor» que use un modelo distinto al del «constructor», para obtener una segunda opinión sobre los PR de los agentes antes de fusionarlos. Ninguna de las dos necesita funciones nuevas de Multica: la API y el modelo de daemon multimáquina ya admiten ambas.
Lo que todavía no estoy haciendo, y probablemente no haré hasta que Multica incorpore disparadores de eventos de GitHub en Autopilot, es sacar mis routines de eventos de GitHub de Claude Managed Agents. Para ese caso de uso gana la superficie de disparadores. Mantendré ambas plataformas, pagaré a Anthropic por aquello en lo que son mejores y ejecutaré el resto en €4,49 de Hetzner.
La diferencia con el autoalojamiento es que, cuando un agente se ejecuta durante dos horas en una tarea, puedo abrir una terminal, entrar por SSH en mi propio servidor, seguir el log del daemon con tail y verlo pensar. Eso vale €4,49 al mes. Puede que valga más.
Si has estado mirando tu propia factura de agentes gestionados y haciéndote la misma pregunta — ¿de verdad necesito esta nube para hacer este trabajo? —, la respuesta, para buena parte del trabajo, es no. Necesitas un VPS, Docker y Tailscale. El resto está documentado.
La terminal te espera.
Si merece la pena autoalojar Multica
Autoalojar Multica en un VPS de Hetzner me dio una alternativa open source a Claude Managed Agents que funciona en mis términos: mis datos, mis claves, mi disponibilidad. Ese control compensa la fricción de la configuración si la privacidad o el coste te importan más que la comodidad de un servicio gestionado.
Requiere más mantenimiento que un servicio alojado, así que entra con los ojos abiertos. Empieza en un droplet barato que puedas reconstruir y apóyate en él solo cuando sea estable.
Si quieres una plataforma de agentes autoalojada montada y reforzada, es algo que hago a través de Ramlit, y documenté una construcción de VPS similar en mi bitácora de despliegue de Hermes y en mi construcción del asistente OpenClaw.
