Railway y Render: plataformas de despliegue sin sorpresas

Actualizado: 2026-05-03

Railway y Render llevan tiempo presentándose como el reemplazo natural de Heroku, pero solo en los últimos dos años han terminado de ganarse ese hueco con fundamento. En octubre de 2025 ambas plataformas han cruzado el umbral donde no son apuestas experimentales sino destinos de producción legítimos para equipos pequeños y medianos. Este artículo recoge impresiones de varios proyectos movidos a una u otra, y de otros tantos que no se movieron, con el razonamiento detrás de cada decisión.

Puntos clave

• Railway encaja en prototipos y servicios con picos de actividad claros; factura por recursos activos, no por tiempo de dyno.
• Render es más predecible en pricing y tiene PostgreSQL gestionado como punto fuerte; los builds son más lentos.
• Ambas plataformas son más fáciles de adoptar que de abandonar; planificar la salida desde el principio reduce el coste de esa decisión futura.
• Por encima de cierto volumen, un VPS propio con Docker Compose sale significativamente más barato; el umbral está más bajo de lo que parece.
• Para un equipo de uno o dos, el coste de oportunidad de operar infraestructura propia supera la diferencia de precio.

El contexto que las hizo crecer

El verano de 2022 fue el punto de inflexión. Heroku anunció el fin del plan gratuito y muchos proyectos pequeños perdieron su opción natural. Railway, que llevaba un par de años en beta, y Render, algo más establecido pero menos conocido, aparecieron en los mismos hilos de Hacker News como alternativas obvias. Las dos ofrecían un modelo parecido en espíritu a Heroku pero construido sobre infraestructura moderna: despliegue desde Git, bases de datos gestionadas, dominios con TLS automático y facturación por uso medido.

Lo que las separa de Heroku es la granularidad de la facturación. 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 esporádicas, la diferencia en la factura es sustancial. Para un proyecto que no para nunca, la diferencia desaparece.

Railway en la práctica

Railway tiene una interfaz que funciona 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 qué un servicio no recibe una variable de otro, ese mapa se lee bien. Para equipos que no están cómodos leyendo YAML de compose, es una ventaja real.

La integración con GitHub es muy directa. Conectas un repositorio, Railway detecta el tipo de proyecto con Nixpacks o con Dockerfile, y cada push a la rama principal redispara un despliegue. Los entornos de vista previa por pull request funcionan y son baratos porque se apagan al cerrar la PR. Esto es útil para revisiones de producto, menos para pruebas automatizadas donde quieres controlar el ciclo de vida del entorno.

Donde Railway ha decepcionado es en el coste efectivo de cargas pequeñas 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 combinación castiga los perfiles que están despiertos siempre aunque apenas hagan trabajo.

Render en la práctica

Render tiene una propuesta más cercana a un PaaS clásico. Servicios web, trabajos en segundo plano, cron, bases de datos: todo en categorías separadas con un tipo concreto de configuración. No hay lienzo visual; hay un panel con listas. Para equipos que vienen de Heroku o de AWS Elastic Beanstalk, el modelo mental es inmediato.

La gestión de bases de datos en Render es un punto fuerte. PostgreSQL gestionado con copias de seguridad automáticas, conexiones SSL, métricas útiles y un precio razonable para los planes intermedios. La migración de un Heroku Postgres a Render Postgres es básicamente un pg_dump y un restore; no hay sorpresas estructurales. Para proyectos que dependen fuertemente de Postgres, Render cubre bien el caso.

Lo que ha costado más en Render es el tiempo de construcción de imágenes. Los builds tardan un orden de magnitud más que en Railway o que en un runner propio. Render cachea capas pero la política de invalidación no siempre aprovecha lo que debería, y un cambio mínimo en dependencias dispara una reconstrucción completa.

El problema común: bloqueo y coste

Las dos plataformas tienen el mismo problema estructural que tenía Heroku: son más fáciles de adoptar que de abandonar. Cuando tu aplicación está 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.

El coste es el otro vector. A partir de cierto volumen, el precio por unidad de cómputo o memoria sube más rápido que en un VPS gestionado por ti. Un servicio que en Hetzner 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.

Esta dinámica conecta con lo que discutimos en Fly.io y el despliegue global: las plataformas gestionadas brillan cuando el requisito de simplicidad es real, no cuando se adoptan por inercia. Para equipos que ya operan contenedores en producción, como los que analizamos en patrones de SQLite en producción, el argumento para pagar la prima del PaaS se debilita.

Dónde encajan y dónde no

Después de varios proyectos en cada plataforma la intuición es más clara:

• Railway encaja muy bien para prototipos y servicios con picos de actividad definidos. La facilidad de desplegar un servicio, conectarle una base de datos y exponerlo en minutos es difícil de superar.
• Render encaja mejor para productos estables que ya tienen tráfico y no quieren pensar en infraestructura. La combinación de servicios web, Postgres gestionado y trabajos en segundo plano cubre una aplicación típica sin fricciones.
• Ninguna ha convencido para cargas muy sensibles al coste o para equipos que ya operan infraestructura propia. Para un equipo que ya tiene Docker Swarm funcionando, añadir Railway o Render no aporta valor suficiente que justifique la factura adicional y el bloqueo.

Cuándo compensa

La decisión entre plataforma gestionada y operación propia depende del tamaño y la fase del equipo. Para un fundador técnico en solitario o un equipo de dos, el coste de oportunidad de operar infraestructura propia es enorme; pagar diez o veinte euros de más al mes es trivial.

Para un equipo de cinco o más ingenieros con al menos una persona con experiencia en operación, 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 año y deja de hacerlo después.

La trampa clásica es quedarse enganchado por inercia. Planificar la salida desde el principio, manteniendo el código lo menos atado posible a las especificidades de cada plataforma, es la forma más sensata de disfrutar la comodidad hoy sin pagar un precio excesivo mañana.

Conclusión

Railway y Render son opciones legítimas para el tramo de equipo pequeño con carga moderada. El momento de revisar la decisión es cuando la factura supera lo que costería operar lo mismo en infraestructura propia y el equipo tiene la madurez para hacerlo. Ese momento llega antes de lo que la mayoría anticipan.