Coolify v5: reescritura multi-servidor del PaaS

Si seguís el mundo del self-hosted PaaS, ya lo viste circular en Hacker News y en el changelog oficial: Coolify —la plataforma que te deja desplegar apps con una experiencia tipo Heroku o Vercel, pero sobre tus propios servidores— arrancó formalmente el desarrollo de su versión 5. Y no es un release de features más: es una reescritura completa del código con un objetivo central bien concreto, correr en serio sobre múltiples servidores. Acá te contamos qué mueve v5 en la carrera post-Vercel, en qué se diferencia de v4 y, sobre todo, qué podés hacer hoy sin esperar a que salga.

Coolify es una plataforma PaaS open source y self-hosted, creada por Andras Bacsai, que despliega aplicaciones, bases de datos y servicios sobre tus propios servidores con una experiencia de un solo clic, al estilo Heroku o Vercel. La versión 5, en desarrollo durante 2026, es una reescritura total del código con foco en escalar en múltiples servidores, una nueva interfaz en Vue/Inertia y una migración automática desde v4.

¿Qué anunció Coolify con la versión 5?

Coolify v5: la reescritura multi-servidor del PaaS self-hosted

Coolify v5 es una reescritura completa del proyecto, no una actualización incremental. El foco declarado es convertir la escalabilidad en varios servidores en una función de primera clase del núcleo, junto con un refactor total del código y una nueva interfaz. Según el issue oficial #5685 de Coolify, el proyecto llegó a v5 después de acumular más de 400 releases en la serie v4, lo que dejó deuda técnica que un refactor pesado busca saldar de raíz.

Los pilares que el propio proyecto enumera:

Escalabilidad de producción en el núcleo. El objetivo es que sumar capacidad sea, en palabras del proyecto, "tan simple como un clic, sin necesidad de pensar para escalar".
Migración automática de v4 a v5. Es la pieza crítica: sin una ruta de upgrade sin fricción, el salto de versión no sería viable para quienes ya tienen instalaciones en producción.
Refactor con estándares estrictos. Coding standards de PHP más rígidos, foco en mantenibilidad y un enfoque test-first, algo que la base v4 —crecida de forma orgánica— no tenía de fábrica.
Nueva UI/UX en Vue/Inertia. Una interfaz reconstruida para una experiencia más simple y moderna, en lugar de parchear la actual.

Sobre la migración, Andras Bacsai lo dejó por escrito en el issue del proyecto: "A fully automated migration from v4 to v5. This is crucial. Without this, version 5 wouldn't be possible." Traducido: una migración totalmente automática de v4 a v5, sin la cual v5 directamente no existiría. Es una señal de que el equipo no piensa quemar a su base instalada con un upgrade manual doloroso.

¿Por qué una reescritura completa y no más features?

Porque el problema de Coolify hoy no es la falta de funciones, sino la escala. La v4 hace muchísimo, pero su arquitectura nació pensada para un servidor principal que orquesta todo. Cuando querés repartir carga en serio entre varias máquinas, aparecen los límites, y esos límites son estructurales, no un bug que se parchea. Reescribir el núcleo es la forma de meter escalabilidad real sin arrastrar decisiones de diseño de hace años.

El contexto ayuda a entender la jugada. De acuerdo con el changelog oficial de Coolify, la v4.0.0 estable recién salió el 27 de abril de 2026, después de casi dos años en beta durante los cuales, según el proyecto, "miles de empresas y personas" ya la corrían en producción. Sobre esa base madura llegaron mejoras rápidas: v4.1.0 (18 de mayo) sumó el build pack Railpack en beta y audit logging estructurado; v4.1.2 (4 de junio) agregó Healthchecks como servicio de un clic y puertos expuestos opcionales para apps sin puerto. Con la v4 por fin estable y pulida, el equipo pudo abrir el frente de v5 sin dejar a nadie colgado.

¿Qué significa "multi-servidor real" y por qué te importa?

Significa pasar de un modelo donde un servidor manda y los demás obedecen, a uno donde escalar horizontalmente es parte del núcleo. Para entender el salto, mirá cómo funciona el multi-servidor hoy en v4, que la documentación oficial califica explícitamente como una función experimental:

El servidor principal construye, los demás solo tiran la imagen. El build corre en la máquina principal, que sube la imagen a un Docker Registry; recién ahí se avisa al resto para que la descarguen y desplieguen. Los servidores remotos no compilan, solo consumen.
Todos los servidores tienen que compartir arquitectura. O todo AMD64 o todo ARM: no podés mezclar. Y necesitás credenciales de login al registry cargadas en cada máquina.
El load balancer es manual. Coolify no lo configura por vos: lo armás a mano por mapeo de puertos o por dominio.
Las acciones se propagan en bloque. Un redeploy, restart o stop impacta en todos los servidores configurados a la vez, con el control centralizado en la instancia principal.

Ese es exactamente el techo que v5 quiere romper: que agregar un servidor y repartir carga sea un flujo nativo y de un clic, no una receta experimental que armás con cuidado. Para un proyecto en crecimiento, la diferencia es enorme: significa poder pasar de "un VPS que aguanta lo que aguanta" a "infraestructura tipo nube, pero sobre servidores tuyos", sin migrar de plataforma.

¿Cuándo sale Coolify v5? ¿Hay fecha?

No hay fecha de release ni timeline público. El milestone de v5 en GitHub —actualizado por última vez el 19 de julio de 2026— no tiene due date asignado, y el equipo fue explícito en que "no lo van a apurar". Traducción práctica: v5 está en marcha y hay commits reales, pero no planifiques nada asumiendo una fecha. El propio proyecto aclara que v4 se sigue manteniendo en paralelo: van a seguir saliendo releases de v4 con normalidad mientras v5 madura. Nadie te va a forzar a saltar.

¿Qué implica esto si tenés apps en producción con Coolify?

En lo inmediato, nada urgente: seguí en v4 con tranquilidad. La reescritura es una noticia de rumbo, no una llamada a actualizar hoy. Pero conviene tener en cuenta tres cosas de acá en adelante:

La migración va a ser automática, no manual. El equipo puso la migración v4→v5 como requisito no negociable, así que cuando llegue el momento el camino debería ser guiado, no un reinstall desde cero. Igual, respaldá siempre antes de cualquier salto de versión mayor.
La UI va a cambiar de base. Al pasar a Vue/Inertia, la interfaz que conocés se rearma. Si documentás procesos internos con capturas de pantalla, prepárate para rehacerlas cuando actualices.
Tu arquitectura multi-servidor puede simplificarse. Si hoy tenés un load balancer y un registry armados a mano para repartir carga, v5 apunta a absorber parte de esa plomería en el núcleo. Vale la pena no sobre-invertir ahora en tooling que la propia plataforma podría reemplazar.

¿Qué podés hacer hoy con Coolify, sin esperar a v5?

Todo lo que necesitás para autoalojar un PaaS ya está en la v4 estable. Si querés probar el enfoque "tu propio Heroku sobre tu servidor", el camino concreto es este:

Levantá un servidor cloud con Docker. Alcanza con un servidor Linux (Ubuntu o Debian) con acceso SSH y Docker instalado. Si venís de nuestra guía sobre instalar Docker Engine en Ubuntu para desplegar en tu Cloud Server, ya tenés la base lista.
Instalá Coolify. Se instala con el script oficial sobre tu servidor; a partir de ahí administrás todo desde su panel web, conectás tu repo de Git y definís despliegues.
Desplegá una primera app. Conectás GitHub o GitLab, elegís el build pack (Nixpacks o el nuevo Railpack en beta) y Coolify se encarga de construir y publicar. Sumá una base de datos o un servicio de un clic desde el catálogo.
Experimentá con multi-servidor si te pinta. Podés sumar un segundo servidor y probar el despliegue distribuido, teniendo presente que hoy es experimental y que v5 lo va a hacer mucho más prolijo.

La gracia de arrancar ahora es que la migración automática promete que ese trabajo no se tira: lo que armes en v4 debería viajar a v5 cuando llegue.

Preguntas frecuentes sobre Coolify v5

¿Coolify v5 ya se puede usar?

No, todavía no hay un release usable de v5. El desarrollo está activo y hay avances en el repositorio, pero no existe versión estable ni fecha. Para producción, la opción es la v4 estable.

¿La migración de v4 a v5 va a ser manual?

No: será automática. El proyecto definió la migración totalmente automatizada de v4 a v5 como un requisito indispensable, sin el cual v5 no sería posible. Aun así, siempre respaldá antes de una actualización mayor.

¿Coolify va a dejar de mantener la v4?

No. El equipo confirmó que va a seguir publicando releases regulares de v4 en paralelo mientras desarrolla v5. No hay presión para saltar de versión.

¿Cuál es la gran novedad técnica de v5?

La escalabilidad multi-servidor como parte del núcleo. Hoy el despliegue en varios servidores es experimental y con configuración manual del load balancer; v5 apunta a que escalar sea nativo y de un clic.

¿Necesito saber PHP para usar Coolify?

No. Coolify está escrito en PHP, pero eso es interno de la plataforma. Vos la usás desde un panel web y desplegás apps de cualquier stack (Node, Python, Go, etc.) sin tocar el código de Coolify.

El panorama, en una línea

Coolify v5 es la señal de que el self-hosted PaaS se toma en serio la escala: dejar de ser "una alternativa liviana a Vercel para un servidor" y volverse infraestructura tipo nube sobre hardware propio. No hay fecha, no hay apuro y la v4 sigue firme, así que la jugada inteligente es la misma de siempre en este ecosistema, arrancar con lo estable de hoy sabiendo que el camino de upgrade ya está siendo diseñado para no dejarte a pie.

Fuentes: