Railway y el PaaS moderno: despliegues WordPress que escalan

El problema con el hosting de siempre

El ciclo de vida tecnologico de la mayoria de los sitios WordPress en produccion sigue un patron predecible: empiezan en un hosting compartido de 10 EUR/mes, migran a un VPS de 50 EUR/mes cuando el compartido se queda corto, y eventualmente acaban en un servidor dedicado o un managed hosting de WordPress (Kinsta, WP Engine) que cuesta entre 100 y 500 EUR/mes.

En cada salto, el proceso de migracion es manual, doloroso y propenso a errores. Los backups son manuales o semi-automaticos. El escalado es vertical: necesitas mas potencia, compras un servidor mas grande. Y el despliegue de cambios es un FTP glorificado o un git pull con los dedos cruzados.

Para la mayoria de sitios corporativos y landing pages, esto funciona. No es elegante, pero funciona. Donde se rompe es cuando necesitas algo mas: multiples entornos (staging, produccion), despliegues atomicos sin downtime, escalado horizontal bajo carga, o cuando gestionas 5-10 sitios WordPress y el coste operativo de mantenerlos se multiplica.

Kubernetes resuelve todos esos problemas, pero introduce una complejidad brutal. Gestionar un cluster de K8s para servir WordPress es como usar un portaaviones para cruzar un rio. Es posible, pero el ratio coste-beneficio no tiene sentido para la mayoria de las organizaciones.

Ahi es donde entra el PaaS moderno. Y Railway es, en nuestra experiencia, la opcion mas pragmatica del mercado actual.

Que es Railway (y que no es)

Railway es una plataforma de infraestructura que abstrae la gestion de servidores, redes y orquestacion. Tu le das codigo (via Git o Dockerfile) y Railway lo construye, despliega y gestiona. Internamente usa contenedores, pero no necesitas saber Docker para usarlo (aunque ayuda).

No es un hosting de WordPress. No tiene panel cPanel, no tiene Softaculous, no tiene un instalador de un click. Es una plataforma de infraestructura donde puedes desplegar 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, servicios de busqueda como Meilisearch.

La diferencia fundamental con un hosting tradicional: Railway trata la infraestructura como codigo. Tu stack se define en configuracion, se despliega con un git push, y se puede reproducir en minutos.

Nuestra arquitectura WordPress en Railway

Llevamos 18 meses desplegando sitios WordPress en Railway para nosotros y para clientes. La arquitectura que hemos estabilizado:

Servicio WordPress. Contenedor Docker basado en una imagen personalizada: PHP 8.3 + FPM, Nginx como servidor web, WP-CLI preinstalado. El codigo del tema y los plugins custom estan en Git. Los plugins de terceros se gestionan con Composer (via wpackagist). El Dockerfile es determinista: misma imagen, mismo resultado, cada vez.

MySQL. Servicio gestionado dentro de Railway. Backups automaticos cada 6 horas con retencion de 7 dias. Para sitios con mas volumen, Railway soporta conexion a bases de datos externas (PlanetScale, AWS RDS).

Redis. Cache de objetos para WordPress via el plugin Redis Object Cache. Reduce la carga a MySQL dramaticamente. En sitios con WooCommerce, Redis es la diferencia entre 200ms y 1.5 segundos en el TTFB de paginas de catalogo.

Volumen persistente. Para wp-content/uploads. Railway proporciona volumenes persistentes vinculados al servicio. Alternativa: almacenar media en S3/Cloudflare R2 via un plugin como WP Offload Media, que es lo que hacemos para sitios con mas de 5 GB de media.

CDN. Cloudflare delante de todo. Cache de paginas completas para visitantes anonimos, minificacion de assets, proteccion DDoS. Configurado via nuestras herramientas de Cloudflare para estandarizar reglas de cache, headers de seguridad y page rules.

Pipeline de despliegue

El flujo de trabajo diario:

1. Desarrollo local con wp-env o Lando.
2. Push a rama de feature en GitHub.
3. Railway detecta el push y construye la imagen Docker automaticamente.
4. Si la rama es main, Railway despliega a produccion con rolling update (zero downtime).
5. Si es otra rama, Railway crea un entorno de preview con URL unica.
6. Post-deploy: flush de cache Redis, flush de rewrites, warming de cache de Cloudflare.

El paso 6 lo automatizamos con un script post-deploy que Railway ejecuta via el campo deploy.startCommand. El mismo script que usamos manualmente con rw-deploy se ejecuta automaticamente.

Resultado: un cambio en el tema de WordPress va de commit a produccion en 3-4 minutos, con zero downtime y rollback instantaneo si algo falla (Railway mantiene las ultimas 5 imagenes desplegadas).

Railway vs hosting tradicional

La comparativa honesta, basada en costes reales de nuestros despliegues:

Criterio	Hosting compartido	VPS gestionado	Managed WP (Kinsta)	Railway
Coste mensual (1 sitio)	10-20 EUR	30-80 EUR	100-300 EUR	15-40 EUR
Despliegue	FTP / Git pull	SSH + scripts	Dashboard + Git	Git push
Downtime en deploy	Variable	Segundos	Segundos	Zero
Staging	Manual / No	Manual	Incluido	Automatico (preview envs)
Escalado	No	Vertical	Limitado	Horizontal
Backups	Diarios (hosting)	Manual o cron	Incluidos	Automaticos
SSL	Let’s Encrypt	Let’s Encrypt	Incluido	Automatico
Reproducibilidad	Baja	Media	Baja	Alta (Docker)

Railway no es el mas barato para un sitio simple. Un hosting compartido de 10 EUR/mes funciona perfectamente para un blog con 5.000 visitas mensuales. Donde Railway gana es en todo lo demas: flujo de trabajo de desarrollo profesional, despliegues fiables, entornos de staging automaticos, y la capacidad de gestionar multiples sitios con la misma arquitectura.

Railway vs Kubernetes

Kubernetes puede hacer todo lo que Railway hace y mucho mas. Pero el coste operativo no es comparable.

Un cluster de EKS (AWS) para servir 3 sitios WordPress cuesta un minimo de 150-200 EUR/mes solo en infraestructura, mas el coste del ingeniero DevOps que lo gestiona. Railway para los mismos 3 sitios cuesta 50-120 EUR/mes y no necesita un DevOps dedicado.

Kubernetes tiene sentido cuando:

• Gestionas 50+ servicios con requisitos de orquestacion complejos.
• Necesitas control granular sobre networking, scheduling y resource limits.
• Tu equipo tiene experiencia en K8s y capacidad para mantenerlo.

Para 3-20 servicios web (WordPress, Next.js, APIs), Railway ofrece el 90% de los beneficios de K8s con el 10% de la complejidad.

Next.js en Railway: la otra mitad

Railway no es solo WordPress. Next.js desplegado en Railway es donde la plataforma brilla con mas fuerza, porque el modelo de despliegue se alinea naturalmente con el framework.

Para sitios como foodplan.pro, el stack es:

• Next.js 15 con App Router.
• Base de datos PostgreSQL gestionada en Railway.
• Redis para sesiones y cache.
• Variables de entorno gestionadas por Railway (sin ficheros .env en produccion).

El despliegue es identico al de WordPress: git push a main, Railway construye, Railway despliega. La ventaja sobre Vercel (la alternativa natural para Next.js) es que Railway te permite desplegar la base de datos, el cache y la aplicacion en la misma plataforma, con networking privado entre servicios. En Vercel necesitas una base de datos externa (Supabase, PlanetScale, Neon), lo que anade latencia y un proveedor mas que gestionar.

El coste comparativo: Vercel Pro cuesta 20 USD/mes por miembro del equipo mas el coste de la base de datos externa. Railway cuesta lo que consumes, tipicamente 15-40 USD/mes para una aplicacion Next.js con base de datos incluida.

Lecciones aprendidas

18 meses de produccion nos han ensenado estas cosas (algunas por las malas):

El build debe ser determinista o pagaras por ello. Si tu Dockerfile usa latest tags o instala dependencias sin lockfile, dos builds del mismo commit pueden producir resultados diferentes. Usamos versiones fijas para todo: imagen base, dependencias PHP (composer.lock), dependencias Node (package-lock.json).

Los volumenes persistentes no son backup. Un volumen persistente de Railway sobrevive a un redespliegue, pero no a un borrado accidental del servicio. Los uploads criticos van a Cloudflare R2 con versionado activado. Leccion aprendida con un susto (no con una perdida, afortunadamente).

Cloudflare cache es imprescindible. Sin cache de CDN, cada visita a un sitio WordPress en Railway consume CPU del contenedor. Con Cloudflare cacheando paginas completas para visitantes anonimos, el 85-90% del trafico no toca el contenedor. Esto reduce drasticamente el coste y mejora el TTFB a < 50ms para contenido cacheado.

Monitoriza el consumo desde el dia uno. Railway factura por consumo. Un plugin de WordPress que dispare un cron cada minuto (si, hemos visto esto) puede generar una factura inesperada. Configuramos alertas de consumo en Railway y revisamos el billing semanalmente.

El onboarding del equipo es rapido. Un desarrollador WordPress que nunca ha tocado Docker puede estar desplegando en Railway en un dia. La curva de aprendizaje es significativamente menor que la de K8s, y el modelo mental (push para desplegar) es familiar para cualquiera que haya usado Heroku.

Cuando Railway no es la respuesta

No todo deberia ir a Railway. Escenarios donde buscamos alternativas:

• Sitios estaticos puros. Cloudflare Pages o Vercel. Gratis, mas rapido, mas simple.
• Aplicaciones con requisitos de compliance estrictos (datos de salud, finanzas reguladas). Railway no ofrece regiones especificas ni certificaciones SOC 2/HIPAA. En esos casos, AWS o GCP con configuracion propia.
• Aplicaciones con picos de trafico masivos y predecibles (Black Friday, eventos). Railway escala, pero no tiene auto-scaling basado en metricas custom como K8s con HPA. Para picos extremos, pre-escalar manualmente o usar una plataforma con auto-scaling nativo.

Para todo lo demas, para el 90% de los sitios web y aplicaciones que construimos y gestionamos, Railway ofrece el equilibrio correcto entre simplicidad, coste y control. No es magia. Es ingenieria bien abstraida. Si tu equipo no tiene DevOps dedicado, nuestra guia de CI/CD para equipos pequenos complementa esta arquitectura.