"Multica en Hetzner: Registro de instalación de Claude Agents autoalojados"

"## Autoalojé Multica en un VPS de Hetzner. Este es el registro de instalación.\n\nLa notificación de factura de Claude Managed Agents llegó a mi bandeja de entrada a las 23:03 de un sábado. Tres sesiones que habían durado más de lo previsto durante un sprint con un cliente — una de ellas había permanecido "inactiva pero técnicamente en ejecución" durante un período que yo, en mi infinita sabiduría, no había pausado. La factura no fue catastrófica. Fue suficiente, sin embargo, para detenerme y hacerme una pregunta que había estado evitando durante dos semanas: si voy a usar agentes de código como compañeros de equipo, ¿realmente necesito la nube de Anthropic para hacerlo?\n\nUna nota rápida sobre el nombre antes de continuar. El resumen en vídeo con el que trabajaba llamaba a esta herramienta Multimodal. El proyecto real en GitHub, el que instalé, se llama Multica — el repositorio es multica-ai/multica, el binario de la CLI es multica y el daemon es multica daemon. Para el resto de esta entrada usaré su nombre real para que los comandos de este registro sean copiables y no meramente aspiracionales.\n\nMultica se presenta como una plataforma de agentes gestionados de código abierto: una capa que convierte los agentes de codificació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 es autoalojable. Todo corre en Docker. Y todo, una vez que lo puse en marcha, reemplazó aproximadamente el 80 % de lo que pagaba al runtime gestionado de Anthropic — a cambio de un VPS de 4,49 € y una molesta pero soluble solución alternativa de autenticación.\n\nEste es el registro de instalación. El servidor de Hetzner que elegí, el arranque de Docker Compose, la edición exacta del archivo env que me permitió superar la pantalla de inicio de sesión rota, la invocación de multica daemon, el primer agente que creé, el cron de Autopilot que configuré para reemplazar una Claude Routine y la comparación honesta al final. Si algo en mi máquina se comportó de forma distinta a lo que prometía la documentación, lo indico en lugar de fingir que el camino fue llano.\n\n## Por qué dejé de fiarme de la factura de Managed Agents\n\nClaude Managed Agents se lanzó en beta pública el 8 de abril de 2026. Dos semanas después tenía cuatro rutinas ejecutándose según un horario, un agente respondiendo a webhooks y una línea de facturación por horas de sesión que se comportaba de forma muy diferente a un cargo típico de API. Managed Agents factura en dos dimensiones — tarifas de token estándar más 0,08 $ por hora de sesión de tiempo de ejecución activo — y la segunda es la que te sorprende. Los tokens de Sonnet 4.6 cuestan 3 $ de entrada / 15 $ de salida por millón. Eso es predecible. Una sesión que permanece en "running" mientras un agente espera a un git clone lento — ese es un contador que no veo correr.\n\nNada de esto es un escándalo. Anthropic es transparente sobre 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 equidad. El problema es el control. Quería saber, hasta el vatio, cuánto costaban mis agentes y qué hacían. Quería poder dejar uno corriendo seis horas sin mirar un panel de control. Quería apuntarlo a un repositorio privado sin conceder acceso a una nube gestionada. Y quería poder cambiar el modelo subyacente — Claude, GLM-4.6, lo que sea que el modelo sigiloso de la semana de Open Code Zen — sin cambiar de plan.\n\nMultica resuelve los cuatro. Ejecutas la plataforma en tu propio hardware. Instalas las CLIs de agentes de código en ese hardware. Le das a Multica las claves de API. Asigna tus issues a los agentes. Observas cómo trabaja. Tu factura es lo que cuesta el modelo subyacente más el VPS.\n\n## Por qué Hetzner — y qué servidor elegí\n\nHe intentado ejecutar este tipo de cargas de trabajo en servidores más baratos antes. El droplet de 4 $/mes que usé para un daemon de Claude Code el otoño pasado no tenía suficiente RAM para ejecutar tres contenedores Docker más un agente que lanzara un espacio de trabajo de Node. La pila predeterminada de Multica son tres contenedores — un backend en Go, un frontend en Next.js/TypeScript y una instancia de Postgres para el almacenamiento de sesiones — y cuando se asigna una tarea a un agente, el daemon genera el proceso de la CLI en esa misma máquina. La pregunta de dimensionamiento no es "¿puede arrancar la pila?" sino "¿puede arrancar la pila y además hacer que Claude Code construya una aplicación React sin que algo muera por OOM?".\n\nElegí Hetzner por dos razones. Primero, la relación calidad-precio en 2026 sigue siendo absurda. Segundo, los nuevos servidores con vCPU compartida del plan CX funcionan con silicon ARM Ampere Altra y los hermanos mayores Intel/AMD en el lado x86, así que podía elegir el que mejor encajara con mi cadena de herramientas. Tras el ajuste de precios de Hetzner del 1 de abril de 2026, el CX22 pasó de 3,29 € a 4,49 €/mes — sigue siendo 2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB de tráfico — y el siguiente nivel, CPX21 en AMD dedicado, ronda los 7,99 €/mes. Empecé con el CX22 solo para ver si el servidor más barato realista podía sostener la pila.\n\nRespuesta corta: sí, para uno o dos agentes a la vez. Si planeas ejecutar cuatro sesiones de Claude Code en paralelo, pasa al CPX21 o superior. El CX22 funcionó bien para un único agente de recuperación tirando de un repositorio privado de GitHub, pero durante una segunda tarea simultánea empezó a paginar en swap.\n\nAntes de desplegar nada, hice lo que siempre olvido y luego lamento: protegí SSH. Solo claves, inicio de sesión con contraseña de root deshabilitado, ufw permitiendo solo 22, 80, 443 y el puerto que fuera a exponer el frontend de Multica. También instalé Docker Engine 27.x (LTS actual a abril de 2026) usando el script de conveniencia oficial, no la versión del repositorio de Ubuntu, porque el archivo compose de Multica usa sintaxis de healthcheck más reciente.\n\n## El arranque: tres contenedores, un archivo env, un inicio de sesión roto\n\nEl README de Multica te da dos rutas de instalación. La primera es la prevista — instala la CLI localmente, apúntala a la UI alojada en Multica Cloud y deja que ellos se encarguen del backend. Esa es la ruta sin fricciones. También es la ruta para la que yo no estaba aquí.\n\nLa segunda es el autoalojamiento completo. Clonas el repositorio, personalizas un archivo env y levantas toda la pila con Docker Compose.\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\nLos tres servicios: db (Postgres 16), backend (API en Go, puerto 8080), frontend (Next.js, puerto 3000). Los healthchecks los encadenan correctamente.\n\nEl primer arranque tardó unos noventa segundos. docker compose ps mostró los tres como saludables. Abrí el frontend en http://<vps-ip>:3000 y me apareció una pantalla de inicio de sesión.\n\nAquí fue donde me topé con el muro. El flujo de autenticación predeterminado de Multica envía un "código reciente" a través del servicio en la nube. Cuando estás completamente autoalojado, ese código nunca llega. Te quedas mirando un campo de entrada de seis dígitos que nunca se resolverá.\n\nLa solución alternativa: abre .env y establece dos valores:\n\nbash\nAPP_ENV=development\nRECENT_API_KEY=\n\n\nAPP_ENV=development le dice al backend que omita la verificación del código en la nube y acepte cualquier código de seis dígitos. Dejar en blanco RECENT_API_KEY elimina la credencial de la nube. Juntos, te ponen en un modo de inicio de sesión de desarrollo donde el primer correo electrónico crea una cuenta y cualquier código de seis dígitos funciona.\n\nTras guardar: docker compose down && docker compose up -d. Escribí 123456 y entré.\n\nVale 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 red VPN Tailscale sin tráfico público llegando al puerto 3000. No está bien cuando el frontend está expuesto a Internet abierto.\n\n## Registrar el daemon y los runtimes\n\nCon la UI en marcha, el siguiente paso es conectar la capa de trabajo real. La UI es donde defines agentes e issues; un proceso daemon separado recoge el trabajo y ejecuta las CLIs de los agentes de codificación.\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\nEn el primer inicio, el daemon detecta automáticamente qué CLIs de agentes están instaladas. Compatibles: claude, codex, openclaw, opencode, hermes, gemini, pi, cursor-agent. Instalé Claude Code y OpenCode. Ambos aparecieron como "connected" en cinco segundos.\n\nEl modelo de token de API te permite ejecutar el daemon en varias máquinas contra una sola UI — una flota de agentes multi-máquina real sin tocar la nube de nadie.\n\nEnvolví el daemon en una unidad systemd:\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## Mi primer agente: un bot de recuperación para mis propias notas\n\nConstruí un NotesBot — un agente con acceso a mi repositorio privado de notas de Obsidian que responde preguntas sin que yo tenga que rebuscar entre archivos Markdown.\n\nCrear un agente requiere dos campos: un nombre y un prompt de sistema.\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\nPara NotesBot lo apunté a OpenCode con GLM-4.6 (contexto de 200K, gratuito durante su ventana actual), configurado con el identificador de modelo zen/big-pickle. El daemon resuelve esto en algo como:\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 no es un nuevo runtime — es un orquestador que delega en runtimes que ya conoces.\n\nMi primer issue: "¿Cuáles de mis notas tratan la distinción entre 'open loops' y 'pattern interrupts' en la estructura de artículos?" El agente lo recogió en cuatro segundos, y veintidós segundos después NotesBot publicó su respuesta con tres nombres de archivo fuente y una marca de confianza "high".\n\n## Configurar Autopilot: el equivalente open-source de Claude Routines\n\nClaude Routines (lanzado el 9 de abril de 2026) ejecuta prompts programados en la infraestructura de Anthropic — cada hora, diariamente, entre semana, semanalmente o ante eventos de webhook/GitHub. Limitado a 5/15/25 ejecuciones por día para Pro/Max/Team.\n\nLa respuesta de Multica es Autopilot — un programador de tareas recurrentes conectado al sistema de issues.\n\nMi configuración:\n- Agente: 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- Cadencia: 0 9 * * * (diariamente a las 9 AM)\n- Zona horaria: Europe/London\n\nSiendo honesto sobre lo que Autopilot no tiene: solo disparadores programados. Sin disparador de webhook de API, sin disparador de evento de GitHub. Y los agentes mueven las tareas a In Review pero no a Done — el humano debe finalizar.\n\n## Comparación honesta: Multica autoalojado vs Claude Managed Agents\n\nCoste: El autoalojamiento gana de forma decisiva. VPS de 4,49 €/mes, sin contador de 0,08 $/hora de sesión. Con mi uso, el VPS se paga en la primera semana.\n\nControl: El autoalojamiento gana. Puedo pausar el daemon, inspeccionar la tabla de sesiones de Postgres, leer los registros del daemon línea a línea e intervenir en tareas atascadas. Sin acceso de terceros a repositorios privados.\n\nSuperficie de disparadores: Claude Managed Agents gana. Las Routines admiten programación + webhook + disparadores de GitHub. Multica Autopilot solo admite programación.\n\nPulido de UX: La interfaz de Claude está más pulida. Multica se siente en una etapa más temprana.\n\nMulti-agente / multi-máquina: El autoalojamiento gana por diseño. Apunta varios daemons de VPS a una sola UI de Multica.\n\nFiabilidad: El runtime de Claude es el runtime de Anthropic — un tiempo de actividad que no puedo igualar en un CX22.\n\nDónde usaría cada uno: Claude Managed Agents para flujos de trabajo de eventos de GitHub. Multica autoalojado para coste, control y escenarios con datos privados.\n\n## Seguridad: lo único que debes hacer bien\n\nAPP_ENV=development en Internet abierto acepta cualquier código de seis dígitos. Eso es peor que no tener autenticación.\n\nRuta uno: VPN de malla Tailscale. Instala Tailscale (curl -fsSL https://tailscale.com/install.sh | sh), configura ufw para que los puertos 3000/8080/SSH solo sean accesibles a través de tailscale0. El frontend en http://100.x.y.z:3000 solo es accesible desde tus propios dispositivos.\n\nRuta dos: completamente local. Ejecuta toda la pila en un portátil o servidor doméstico que nunca toque Internet público.\n\nSea cual sea la ruta que elijas: mantén las imágenes de Docker actualizadas, mantén parcheado el kernel del host y trata APP_ENV=development como exclusivo de red privada.\n\n## Qué construiría a continuación\n\n(1) Conectar CI a la API de creación de issues de Multica para que las compilaciones fallidas generen issues de depuración automáticamente. (2) Ejecutar un segundo daemon en VPS dedicado a un agente "revisor" con un modelo diferente para revisiones de segunda opinión en PRs de agentes.\n\nLa factura de Claude Managed Agents ha bajado un 60 % desde que trasladé la recuperación y el trabajo de prompts programados a Multica. El contador de horas de sesión es una partida mucho más pequeña.\n\nSi has estado haciéndote la misma pregunta que me hice aquel sábado por la noche — ¿realmente necesito esta nube para hacer este trabajo? — la respuesta, para al menos el 80 % del trabajo, es no. Necesitas un VPS, Docker, Tailscale y unas dos horas.\n\nEl terminal está esperando.\n\n## Trabajemos juntos\n\n¿Quieres construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.\n\n* Fiverr (soluciones personalizadas e integraciones): fiverr.com/s/EgxYmWD\n* Portfolio: mejba.me\n* Ramlit Limited (soluciones empresariales): ramlit.com\n* ColorPark (diseño y marca): colorpark.io\n* xCyberSecurity (servicios de seguridad): xcybersecurity.io"