Todas mis apps corren en servidores que provisiono yo mismo. No porque me encante hacer la de DevOps, sino porque soy desarrollador indie en México. Y una suscripción en dólares nunca es solo un cafecito.

Por años, la herramienta que me hacía esto más fácil fue Eddy, un panel open source de gestión de servidores. Lo usaba todos los días para aprovisionar servidores, desplegar mis apps de Laravel, renovar certificados SSL, mantener vivos los daemons de colas, hacer backups. El proyecto ya llevaba años archivado por el autor, y lo sabía. Pero como seguía funcionando, no me preocupaba.

Hasta que Ubuntu lanzó la 26.04 LTS. Intenté aprovisionar un servidor nuevo con ella y simplemente no pude. Ahí fue cuando Eddy se rompió. Con el proyecto archivado y su framework abandonado por el mismo autor, nadie iba a venir a arreglarlo. Y yo lo necesitaba todos los días.

Obviamente, la alternativa más conocida es Forge, del creador de Laravel. Muy buen software, que pagaría con gusto si su precio me cuadrara. Pero su plan básico de 12 dólares al mes (144 al año, unos 2,400 pesos) solo permite conectar un servidor externo. Todos los demás deben ser Laravel VPS, que forzosamente corren sobre la infraestructura de DigitalOcean. Para gestionar más máquinas externas, el plan sube de precio. Y esa matemática no me sale.

Así que le pedí a la IA que me reconstruyera Eddy por completo, a partir del código open source, pero esta vez en un stack que me permitiera mantenerlo al menos la próxima década: Laravel Livewire. Pasamos 20 minutos acordando un plan que yo debía aprobar antes de implementar. Lo implementó todo en 50 minutos, y pasé el resto del día probando cada uno de los flujos: provisionar servidores, deploys, bases de datos, daemons, crons, reglas de firewall. Y solo encontré bugs cosméticos.

El resultado es Anti Fuse, un panel que provisiona cualquier VPS con Ubuntu 26.04 y deja tu app de Laravel en producción en minutos. Es la herramienta que uso todos los días para mandar a producción todas mis apps. Soy su usuario número uno, y mi incentivo es que funcione para mí, no hacerme rico. Así que es gratis. No freemium — gratis. Como de cualquier forma la corro para mí, dejarte usarla apenas me cuesta.

En este post: por qué lo construí, cómo fue exactamente la reconstrucción con IA (incluyendo lo que sí se rompió), qué hace Anti Fuse y qué no (todavía sin monitoreo de servidores), qué pasa cuando salga la próxima LTS, y cómo aprovisionar tu primer servidor online.

Por qué un panel

Una app de Laravel no va por sí sola en un servidor: necesita PHP, MySQL, Redis, un servidor web, SSL y firewall. Hacerlo a mano por SSH es un trabajo colosal. Lo intenté: todo un día buscando tutoriales desactualizados, y al final cada servidor queda instalado de forma distinta. Un panel hace que todo esto sea igual en cada ocasión: le das un VPS y el resultado es un servidor de producción igual que todos los demás.

Eddy era mi panel para esto. Era open source, gratis, y lo usaba todos los días. Esta es la historia de cómo lo reemplacé.

La solución

Anti Fuse es un panel web, hospedado y gratis. Conectas tu VPS y en unos 20 minutos tienes un servidor de producción listo para desplegar tus apps de Laravel, sin abrir la terminal. Despliegas en dos minutos, aproximadamente: conectas GitHub, eliges el repo y la branch, y automáticamente tienes el primer deploy. Sin downtime, SSL automático, backups, colas, crons. Puedes provisionar cualquier VPS con Ubuntu 26.04 y un usuario root, o crear servidores desde el panel vía las APIs de DigitalOcean y Hetzner.

Operarlo me cuesta 3.90 euros al mes. Por eso es gratis: yo lo corro para mí, y dejarte usarlo apenas me cuesta algo.

Pero la historia que todo el mundo me pide es la del rebuild. Aquí va, con números.

El rebuild: 20 minutos de planeación, 50 de implementación

Usé ZCode, un agente de código, con GLM 5.3. Le di el código open source de Eddy y la instrucción de reconstruirlo todo en Laravel Livewire, un framework que me permite mantenerlo por la próxima década.

Primero, el plan: incluía cada módulo a reconstruir (aprovisionamiento, deploys, SSL, daemons), con el mapeado de Eddy a Livewire y el orden de las fases de implementación. Revisar el plan fue honestamente superficial, porque tenía todo el sentido del mundo para mí. Solo veté una cosa: la IA quería usar polling para conocer en tiempo real el estado de los deploys y del aprovisionamiento. Le dije que no, que usara broadcasting con Reverb. Y esa fue la única decisión de arquitectura que aporté yo.

El plan lo implementó por completo en 50 minutos: unas 15,000 líneas de código de aplicación y 11,600 de tests que la IA escribió por su cuenta. Con vistas, migraciones y configuración, el proyecto completo llega a ~40,400 líneas.

¿Y qué fue lo que en verdad no funcionó? Del backend, casi nada. Pero un fallo real sí hubo: al elegir el repositorio de GitHub, se guardaba solo el endpoint (/antihq/fuse) y no la URL completa (https://… o git@…). Y el deploy moría en la clonación por este problema. Lo demás eran cuestiones cosméticas del frontend: el selector de tipo de SSL, donde puedes elegir Caddy automático, certificado propio o sin Caddy, era un grupo de radios, y al hacer clic en uno se seleccionaban todos. Loading states ausentes, campos anidados mal conectados. Una interfaz cruda, pero como primer borrador, funcionaba.

El soporte de Ubuntu 26.04 vino después. Aquí el agente hizo arqueología de dependencias por sí solo: descubrió que el repositorio externo con el que Eddy instalaba PHP ya no existe en 26.04, así que usó el de Ubuntu. Que MySQL ahora instala la 8.4 por defecto. Y que Redis ya ni se puede instalar: lo cambió por Valkey. Yo no toqué nada. Al final provisioné un servidor de prueba con la nueva Ubuntu y, sorprendentemente, todo funcionó a la primera.

¿Y cuándo salga la próxima LTS? Es simplemente cuestión de pedirle a la IA que revise los scripts de aprovisionamiento y los adapte. Y como funcionó para la 26.04, sé que esto funciona.

Después de todo esto, hubo una semana de dogfooding. Migré mis despliegues reales de Eddy a Anti Fuse, y cada día hacía lo mismo: decirle a la IA "estoy revisando esto, este elemento está fallando", y lo corregía. Usarlo en mis casos reales fue la fase de calidad. Los tests de la IA nunca hubieran encontrado lo que encuentra uno por usarlo de verdad.

Las preguntas difíciles

¿Qué accesos le estaré dando? Anti Fuse es hospedada, no self-hosted. Los datos sensibles se guardan encriptados en la base de datos con la APP_KEY de Laravel; yo soy el único que tiene acceso a la llave de cifrado. Lo que la plataforma guarda es: el token de tu proveedor, solo para crear, eliminar y listar servidores; las contraseñas de las bases de datos de tus apps; y un par de llaves SSH por usuario. La plataforma genera uno para cada usuario, nunca se comparten entre cuentas, y tus llaves privadas siguen siendo tuyas. La conexión a tu VPS no depende de contraseña root: al provisionar, Anti Fuse registra su llave pública en el servidor y desde ahí opera por SSH con esa llave. Con DigitalOcean y Hetzner es igual: el servidor se crea por API, Anti Fuse añade su llave, y con ella provisiona y corre los scripts de deploy. Y para ser honesto: aún no hay un log de acceso.

¿Y si mañana la dejo? No es open source, pero llevo más de 10 años desarrollando Laravel y siempre voy a necesitar desplegar aplicaciones. El incentivo de mantenerla es totalmente estructural, no solo una promesa. Y si llegara el día en que por alguna razón la dejara, publico el código.

¿Por qué no Coolify? La probé. Generalista y centrada en Docker, así que nunca encajó en mi flujo. Y Docker exige servidores más caros; Anti Fuse instala todo nativo y corre en el VPS más básico de cualquier proveedor. Y con la era de la IA, reconstruir lo que ya conocía era mucho más rápido que forzarme a adaptarme a la filosofía de otro proyecto.

¿El costo real? El panel corre en un VPS de 3.90 euros (4 GB, 2 CPUs) con SQLite. Hoy soy el único usuario; los límites a escala los desconozco, pero si crece, puede escalar con MySQL externo o un VPS más grande. Otra de las limitaciones es que no se aceptan servidores que ya corran apps, únicamente instalaciones limpias con la última Ubuntu. Y todavía no hay un monitoreo de servidores.

¿Deploy sin downtime? Se hace uso de Caddy más directorios de release, con hooks para antes y después del deployment, útiles para ejecutar migraciones, workers, assets, lo que sea que tu app necesite.

Empieza aquí

Crea tu cuenta en fuse.antihq.com/register. Añade tu llave SSH pública. Conecta la API de DigitalOcean o Hetzner, o cualquier VPS limpio con Ubuntu 26.04. Crea el servidor, apunta el registro A de tu dominio a la IP de tu VPS, conecta GitHub y crea el sitio con tu dominio y tu repositorio: automáticamente se hace el primer deploy, y solo toma dos minutos. La landing está en antihq.com/fuse.

Por qué lo comparto

Si la herramienta que necesitas, o que usas día a día, murió o no te alcanza, reconstruirla con IA es una opción real. Cuesta menos de lo que crees: 70 minutos me dieron 15,000 líneas de código funcionales. Pero no es gratis-gratis. El precio que pagas es hacerte cargo del mantenimiento. Yo lo acepté porque esta herramienta es mi pan de cada día para ejercer mi profesión.

Y una cosa más: casi todas las herramientas que usamos vienen de Estados Unidos o Europa, y en inglés. Esta la hizo un mexicano, está en español. Para los devs de LATAM, para demostrar que también podemos construir lo que necesitamos y usamos.

Si quieres probarla, despliega un servidor de prueba. Si te sirve, úsala.