La línea de tiempo del PaaS self-hosted, y de dónde viene realmente la idea

Toda “alternativa a Heroku” suena a idea nueva hasta que miras la línea de tiempo real —la categoría se ha reconstruido con un equipo nuevo más o menos cada pocos años desde el propio Heroku, y lo que sigue cambiando no es la promesa central (git push, obtén una app corriendo), es quién posee la infraestructura debajo.

La era de todo administrado

Heroku (2007) definió la forma que todos siguen copiando: buildpacks, dynos, add-ons, un git push que se convierte en un despliegue. Adquirida por Salesforce en 2010, y durante casi una década “PaaS” básicamente significó “Heroku, o algo que intenta ser Heroku”. La contrapartida fue siempre la misma: una facilidad extraordinaria, sobre infraestructura que nunca tocas y nunca posees.

Fly.io (2017) y Render (2018) mantuvieron ese mismo modelo de todo administrado pero atacaron partes distintas de él —Fly se construyó alrededor de correr VMs cerca de los usuarios globalmente en vez de en una sola región; Render fue tras el dolor específico de equipos que perdían tiempo de ingeniería real en plomería de infraestructura en vez de trabajo de producto. Ninguno cambió quién posee el servidor. Railway (fundada el 9 de junio de 2020, por Jake Cooper) empujó el mismo modelo hacia una energía de activación casi cero —la brecha más pequeña posible entre “tengo código” y “está corriendo”.

La otra rama: nunca hospedar la app del cliente

Cloud 66, fundada en 2012, hizo una apuesta completamente distinta, años antes de que fuera tendencia: un plano de control sobre servidores que el cliente ya posee, en vez de una plataforma que posee los servidores en sí. Ese es el verdadero punto de origen del modelo que sigue Railyard —no una idea reciente, sino una de 2012 que tardó mucho en volverse obviamente correcta a medida que las facturas de la nube crecían y el lock-in de proveedor se volvía más caro de ignorar.

Coolify tomó ese mismo hilo de servidor propio desde el lado open-source —lanzada por primera vez el 24 de marzo de 2021, y para la primavera de 2026 superando las 50,000 estrellas en GitHub, reportadamente el PaaS self-hosted más reconocido hasta la fecha. Gratis, self-hosted, operado enteramente por ti, incluyendo el propio plano de control.

Dónde deja eso la decisión real

El eje real no es “qué plataforma tiene más funciones” —toda plataforma de esta lista termina convergiendo en buildpacks, bases de datos administradas y despliegues sin downtime. El eje que se ha mantenido estable por más de una década es quién posee la máquina: de Heroku a Railway te rentan todo el stack; de Cloud 66 a Railyard y Coolify te dan un flujo de trabajo sobre infraestructura que es tuya. Dentro de ese segundo grupo, la siguiente pregunta es igual de antigua —un plano de control administrado que no operas tú (Cloud 66, Railyard) frente a un plano de control self-hosted que también corres tú mismo (Coolify). Ninguno es estrictamente mejor; son respuestas distintas a cuánta infraestructura quieres operar personalmente, y esa ha sido la decisión real desde 2012, no una nueva.

Por qué la categoría se sigue reconstruyendo en vez de consolidarse

Nadie ha ganado esto de forma definitiva porque la contrapartida nunca se resuelve en una sola dirección —cada pocos años, un equipo nuevo decide que el líder actual se alejó demasiado hacia la complejidad, el precio o el lock-in, y construye una versión más simple de la misma idea central. Eso no es señal de que el problema esté sin resolver; es señal de que la respuesta real es “depende de cuánta infraestructura quieras poseer”, lo cual no tiene una única respuesta correcta que vuelva obsoleto al resto de la categoría.

Mira cómo se compara Railyard específicamente: Heroku, Railway, Render, Fly, Cloud 66.