Railway y Render llevan tiempo presentandose como el reemplazo natural de Heroku, pero solo en estos dos ultimos anios han terminado de ganarse ese hueco con fundamento. En octubre de 2025 ambas plataformas han cruzado ya el umbral donde no son apuestas experimentales sino destinos de produccion legitimos para equipos pequenios y medianos. Este post recoge impresiones de varios proyectos que he movido a una u otra y de otros tantos que he decidido no mover, con el detalle de por que en cada caso.
El contexto que las hizo crecer
El verano de 2022 fue el punto de inflexion. Heroku anuncio el fin del plan gratuito y muchos proyectos pequenios se quedaron sin su opcion natural. Railway, que llevaba un par de anios en beta, y Render, algo mas establecido pero menos conocido, aparecieron en los mismos hilos de Twitter y Hacker News como alternativas obvias. Las dos ofrecian un modelo parecido en espiritu a Heroku pero construido sobre infraestructura moderna: despliegue desde Git, bases de datos gestionadas, dominios con TLS automatico y facturacion por uso medido.
Lo que las separa de Heroku es la granularidad de la facturacion. Heroku cobraba por dyno-hora en bloques relativamente grandes. Railway y Render cobran por uso real de CPU, memoria y red. Para un proyecto que pasa el 90 por ciento del tiempo parado entre peticiones esporadicas, la diferencia en la factura es sustancial. Para un proyecto que no para nunca, la diferencia desaparece.
Railway en la practica
Railway tiene una interfaz que entiendo como un mapa de servicios. Cada proyecto es un lienzo donde arrastras bases de datos, aplicaciones, colas y variables de entorno, y la plataforma se encarga de conectarlas. Este modelo visual no es gratuito: cuando tienes que depurar por que un servicio no recibe una variable de otro, ese mapa se lee bien. Para equipos que no estan comodos leyendo YAML de compose, es una ventaja real.
La integracion con GitHub es muy directa. Conectas un repo, Railway detecta el tipo de proyecto con Nixpacks o con Dockerfile, y cada push a la rama principal redispara un despliegue. Los entornos de preview por pull request funcionan y son baratos porque se apagan al cerrar la PR. Esto ultimo es util para revisiones de producto, menos para pruebas automatizadas donde quieres controlar el ciclo de vida del entorno.
Donde Railway me ha decepcionado es en el coste efectivo de cargas pequenias pero constantes. Un servicio que consume 256 MB de memoria y 0,1 CPU constantes durante todo el mes tiene un precio que no es competitivo frente a un VPS barato con Docker Compose. Railway factura por tiempo activo y por recursos reservados, y esa combinacion castiga los perfiles que estan despiertos siempre aunque apenas hagan trabajo. Para servicios con picos claros y valles largos encaja mejor.
Render en la practica
Render tiene una propuesta mas cercana a un PaaS clasico. Servicios web, trabajos en segundo plano, cron, bases de datos, todo en categorias separadas con un tipo concreto de configuracion por cada uno. No hay lienzo visual; hay un panel con listas. Para equipos de ingenieria que vienen de Heroku o de AWS Elastic Beanstalk, el modelo mental es inmediato.
La gestion de bases de datos en Render es un punto fuerte. PostgreSQL gestionado con copias de seguridad automaticas, conexiones SSL, metricas utiles y un precio razonable para los planes intermedios. La migracion de un Heroku Postgres a Render Postgres es basicamente un pg_dump y un restore; no hay sorpresas estructurales. Para proyectos que dependen fuertemente de Postgres y no quieren montar HA por su cuenta, Render cubre bien el caso.
Lo que me ha costado mas en Render es el tiempo de construccion de imagenes. Los builds tardan un orden de magnitud mas que en Railway o que en un runner propio. Render cachea capas pero la politica de invalidacion no siempre aprovecha lo que deberia, y un cambio minimo en dependencias dispara una reconstruccion completa. Para aplicaciones con dependencias pesadas, esto suma minutos a cada despliegue.
El problema comun: bloqueo y coste
Las dos plataformas tienen el mismo problema estructural que tenia Heroku: son mas faciles de adoptar que de abandonar. Cuando tu aplicacion esta conectada a su base de datos gestionada, a su sistema de secretos y a su pipeline de despliegue, sacarla fuera requiere reconstruir esas tres piezas en otro sitio. Para un proyecto pequenio esto es semanas de trabajo; para un proyecto grande, meses.
El coste es el otro vector. Tanto Railway como Render tienen precios razonables para cargas pequenias y medias. A partir de cierto volumen, el precio por unidad de computo o memoria sube mas rapido que en un VPS gestionado por ti. Un servicio que en Hetzner o DigitalOcean cuesta 20 euros al mes puede salir por 60 u 80 en Render con equivalente de recursos. La diferencia se paga en operaciones que no tienes que hacer, pero si tu equipo ya sabe operar, esa diferencia es coste puro.
Donde encajan y donde no
Despues de varios proyectos en cada plataforma tengo una intuicion mas clara. Railway encaja muy bien para prototipos y para servicios con picos de actividad definidos. La facilidad de desplegar un servicio, conectarle una base de datos y exponerlo en minutos es dificil de superar. Para un fin de semana de hackathon o para validar una idea, es mi primera eleccion.
Render encaja mejor para productos estables que ya tienen trafico y no quieren pensar en infraestructura. La combinacion de servicios web, Postgres gestionado y trabajos en segundo plano cubre una aplicacion tipica web sin fricciones. Los precios se vuelven menos agradables cuando el producto crece, pero para el tramo de 100 a 10.000 usuarios activos Render funciona.
Ninguna de las dos me ha convencido para cargas muy sensibles al coste o para equipos que ya operan infraestructura propia. Para un equipo que ya tiene Swarm o Kubernetes funcionando, anadir Railway o Render no aporta valor suficiente que justifique la factura adicional y el bloqueo. Es mas barato y mas limpio seguir operando lo que ya funciona.
Cuando compensa
La decision entre plataforma gestionada y operacion propia depende mucho del tamanio y la fase del equipo. Para un fundador tecnico en solitario o un equipo de dos personas, el coste de oportunidad de operar infraestructura propia es enorme; pagar diez o veinte euros de mas al mes por que Railway o Render se encarguen es trivial.
Para un equipo de cinco o mas ingenieros con al menos una persona con experiencia en operacion, la cuenta cambia. El tiempo agregado se diluye y la factura de la plataforma gestionada se acumula. Conviene evaluar entonces si el valor del PaaS justifica el coste; muchas veces lo justifica durante el primer anio y deja de hacerlo despues.
La trampa clasica es quedarse enganchado por inercia. Un dia descubres que pagas mil euros al mes por algo que en infraestructura propia costaria doscientos. Planificar la salida desde el principio, manteniendo el codigo lo menos atado posible a las especificidades de cada plataforma, es la forma mas sensata de disfrutar la comodidad hoy sin pagar un precio excesivo manana.
