Railway y el PaaS moderno: despliegues WordPress que escalan

El problema con el hosting de siempre

La mayoría de los sitios WordPress en producción siguen el mismo recorrido: empiezan en un hosting compartido, pasan a un VPS cuando el compartido se queda corto y acaban en un servidor dedicado o en un hosting gestionado de WordPress (Kinsta, WP Engine).

En cada salto, la migración es manual y propensa a errores. Los backups dependen de un cron o de la buena memoria de alguien. El escalado es vertical: si hace falta más potencia, se compra un servidor más grande. Y el despliegue de cambios suele ser una subida por FTP o un git pull en el servidor.

Para un sitio corporativo o una landing, esto funciona. Se rompe cuando hace falta algo más: varios entornos (staging y producción), despliegues atómicos sin caída, escalado horizontal bajo carga, o cuando un equipo mantiene entre 5 y 10 sitios y el coste operativo se multiplica.

Kubernetes resuelve todo eso, pero a cambio de mucha complejidad. Montar un cluster para servir WordPress tiene sentido en pocas organizaciones; para la mayoría, el coste de operarlo supera el beneficio.

Ese hueco es el que ocupa el PaaS moderno, y Railway es una de las opciones más directas para equipos pequeños.

Qué es Railway (y qué no es)

Railway es una plataforma de infraestructura que abstrae servidores, red y orquestación. Recibe código (desde un repositorio Git o un Dockerfile), lo construye, lo despliega y lo mantiene en marcha. Por dentro usa contenedores, pero no exige dominar Docker para empezar.

No es un hosting de WordPress: no tiene cPanel ni instalador de un clic. Es una plataforma donde se despliega cualquier cosa que corra en un contenedor: WordPress con PHP-FPM y Nginx, Next.js, APIs en Python, bases de datos MySQL o PostgreSQL, Redis o un buscador como Meilisearch.

La diferencia de fondo con el hosting tradicional es que la infraestructura queda descrita en configuración: se despliega con un git push y se puede reproducir en otro proyecto en minutos.

Arquitectura de referencia para WordPress en Railway

Una arquitectura razonable para un WordPress de empresa en Railway tiene cinco piezas.

Servicio WordPress. Un contenedor con imagen propia: PHP 8.3 con FPM, Nginx como servidor web y WP-CLI instalado. El tema y los plugins propios viven en Git; los de terceros se gestionan con Composer (vía wpackagist). Con versiones fijadas, el mismo commit produce siempre la misma imagen.

MySQL. Un servicio de base de datos dentro del mismo proyecto, en la red privada. Conviene activar copias periódicas y comprobar cada cierto tiempo que se restauran. Para volúmenes grandes, WordPress puede apuntar a una base de datos externa.

Redis. Cache de objetos mediante el plugin Redis Object Cache. Quita carga a MySQL, y en tiendas WooCommerce con catálogos grandes es de las mejoras que más se notan en el tiempo de respuesta.

Volumen persistente. Para wp-content/uploads. Railway monta volúmenes persistentes en el servicio. Cuando la biblioteca de medios crece mucho, la alternativa habitual es llevarla a un almacenamiento de objetos compatible con S3 mediante un plugin como WP Offload Media.

Cache delante. Una CDN o un proxy de cache para servir páginas completas a visitantes anónimos. Sin esa capa, cada visita consume CPU del contenedor, y en una plataforma que factura por consumo eso se paga.

Flujo de despliegue

El flujo diario queda así:

1. Desarrollo en local con wp-env o Lando.
2. Push a una rama en GitHub.
3. Railway detecta el push y construye la imagen.
4. Si la rama es main, despliega en producción sin caída: el contenedor nuevo entra antes de retirar el anterior.
5. Si es otra rama, se puede crear un entorno de previsualización con su propia URL.
6. Después del despliegue: vaciar la cache de objetos y las reglas de reescritura, y precalentar la cache de páginas.

El paso 6 se automatiza con un script que se ejecuta al arrancar el servicio. Con esto, un cambio en el tema pasa de commit a producción en pocos minutos, y si algo falla se vuelve al despliegue anterior desde el panel.

Railway frente al hosting tradicional

Criterio	Hosting compartido	VPS gestionado	WordPress gestionado	Railway
Coste para un sitio	Bajo	Medio	Alto	Bajo a medio, según consumo
Despliegue	FTP o git pull	SSH y scripts	Panel y Git	Git push
Caída al desplegar	Variable	Segundos	Segundos	Ninguna si está bien configurado
Staging	Manual o inexistente	Manual	Incluido	Entornos por rama
Escalado	No	Vertical	Limitado	Vertical y réplicas
Backups	Los del proveedor	Manual o cron	Incluidos	Configurables por servicio
SSL	Let’s Encrypt	Let’s Encrypt	Incluido	Automático
Reproducibilidad	Baja	Media	Baja	Alta (contenedores)

Railway no es lo más barato para un sitio sencillo: un blog con poco tráfico funciona bien en un hosting compartido. Donde aporta es en el resto: un flujo de trabajo profesional, despliegues fiables, entornos de prueba automáticos y la posibilidad de llevar varios sitios con la misma arquitectura.

Railway frente a Kubernetes

Kubernetes hace todo lo que hace Railway y mucho más, pero su coste de operación no es comparable. Un cluster gestionado (EKS, GKE, AKS) cobra por el plano de control y los nodos aunque los sitios tengan poco tráfico, y alguien del equipo tiene que mantenerlo.

Kubernetes tiene sentido cuando:

• hay decenas de servicios con necesidades de orquestación complejas;
• hace falta control fino sobre red, planificación y límites de recursos;
• el equipo ya tiene experiencia con Kubernetes y tiempo para mantenerlo.

Para un puñado de servicios web (WordPress, Next.js, APIs), un PaaS como Railway cubre la mayor parte de esos beneficios con mucha menos operación.

Next.js en Railway

Railway no es solo WordPress. Next.js encaja bien con su modelo de despliegue. Un stack típico:

• Next.js con App Router.
• PostgreSQL en el mismo proyecto.
• Redis para sesiones y cache.
• Variables de entorno gestionadas por la plataforma, sin ficheros .env en producción.

El despliegue es igual que el de WordPress: push a main, build y despliegue. Frente a Vercel, la alternativa natural para Next.js, la diferencia es que en Railway la base de datos, la cache y la aplicación viven en la misma plataforma con red privada entre ellas. En Vercel la base de datos suele ser un proveedor externo (Supabase, Neon y similares), lo que añade otro proveedor que gestionar.

En coste, Vercel cobra el plan Pro por miembro del equipo, más la base de datos aparte; Railway factura por consumo. Cuál sale más barato depende del tamaño del equipo y del tráfico, así que conviene calcularlo con los precios vigentes de ambos.

Buenas prácticas

Builds deterministas. Si el Dockerfile usa etiquetas latest o instala dependencias sin lockfile, dos builds del mismo commit pueden dar resultados distintos. Hay que fijar versiones de todo: imagen base, dependencias PHP (composer.lock) y Node (package-lock.json).

Un volumen no es un backup. Un volumen persistente sobrevive a un redespliegue, pero no al borrado del servicio. Los ficheros críticos necesitan una copia fuera de la plataforma, idealmente con versionado.

Cache delante, siempre. Con las páginas de visitantes anónimos servidas desde cache, la mayor parte del tráfico no llega al contenedor: baja el consumo y mejora el tiempo de respuesta.

Vigilar el consumo desde el primer día. Railway factura por uso. Un plugin que lance un cron cada minuto puede disparar la factura. Conviene fijar límites y alertas de gasto y revisar el consumo con regularidad.

Curva de aprendizaje corta. Un desarrollador de WordPress que no ha usado Docker puede desplegar en Railway en poco tiempo. El modelo mental (push para desplegar) es familiar para quien haya usado Heroku.

Cuándo Railway no es la respuesta

• Sitios estáticos puros. Plataformas de hosting estático como Cloudflare Pages o Netlify son más simples y suelen tener un plan gratuito suficiente.
• Requisitos de cumplimiento estrictos (datos de salud, finanzas reguladas, residencia de datos). Antes de elegir, hay que comprobar en la documentación de seguridad de Railway las certificaciones y regiones vigentes y si cubren el caso. Si no, AWS, GCP o servidores propios con configuración a medida.
• Picos de tráfico extremos. Railway permite réplicas, pero el autoescalado por métricas propias es más limitado que el de Kubernetes con HPA. Para picos muy grandes, conviene escalar de antemano o usar una plataforma con autoescalado nativo.

Para el resto de sitios web y aplicaciones de tamaño medio, Railway ofrece un buen equilibrio entre simplicidad, coste y control. Si el equipo no tiene a nadie dedicado a DevOps, la guía de CI/CD para equipos pequeños complementa esta arquitectura.