Railway and Modern PaaS: WordPress Deployments That Scale

The problem with traditional hosting

The lifecycle of most production WordPress sites follows a predictable pattern: start on shared hosting at EUR 10/month, migrate to a VPS at EUR 50/month when shared falls short, eventually land on a dedicated server or managed WordPress hosting (Kinsta, WP Engine) costing EUR 100-500/month.

At every jump, the migration process is manual, painful, and error-prone. Backups are manual or semi-automated. Scaling is vertical: need more power, buy a bigger server. And deploying changes is a glorified FTP upload or a git pull with fingers crossed.

For most corporate sites and landing pages, this works. It’s not elegant, but it works. Where it breaks is when you need more: multiple environments (staging, production), atomic zero-downtime deployments, horizontal scaling under load, or when you manage 5-10 WordPress sites and the operational cost of maintaining them multiplies.

Kubernetes solves all those problems but introduces brutal complexity. Managing a K8s cluster to serve WordPress is like using an aircraft carrier to cross a river. Possible, but the cost-benefit ratio makes no sense for most organizations.

That’s where modern PaaS enters. And Railway is, in our experience, the most pragmatic option on the market today.

What Railway is (and isn’t)

Railway is an infrastructure platform that abstracts away server, network, and orchestration management. You give it code (via Git or Dockerfile) and Railway builds, deploys, and manages it. It uses containers internally, but you don’t need to know Docker to use it (though it helps).

It’s not a WordPress host. No cPanel, no Softaculous, no one-click installer. It’s an infrastructure platform where you can deploy anything that runs in a container: WordPress with PHP-FPM and Nginx, Next.js, Python APIs, MySQL or PostgreSQL databases, Redis, search services like Meilisearch.

The fundamental difference from traditional hosting: Railway treats infrastructure as code. Your stack is defined in configuration, deployed with a git push, and reproducible in minutes.

Our WordPress architecture on Railway

We’ve been deploying WordPress sites on Railway for 18 months, for ourselves and clients. The architecture we’ve stabilized:

WordPress service. Docker container based on a custom image: PHP 8.3 + FPM, Nginx as web server, WP-CLI pre-installed. Theme and custom plugin code lives in Git. Third-party plugins are managed with Composer (via wpackagist). The Dockerfile is deterministic: same image, same result, every time.

MySQL. Managed service within Railway. Automatic backups every 6 hours with 7-day retention. For higher-volume sites, Railway supports connections to external databases (PlanetScale, AWS RDS).

Redis. Object cache for WordPress via the Redis Object Cache plugin. Dramatically reduces MySQL load. On WooCommerce sites, Redis is the difference between 200ms and 1.5 seconds TTFB on catalog pages.

Persistent volume. For wp-content/uploads. Railway provides persistent volumes bound to the service. Alternative: store media in S3/Cloudflare R2 via a plugin like WP Offload Media, which is what we do for sites with over 5 GB of media.

CDN. Cloudflare in front of everything. Full page cache for anonymous visitors, asset minification, DDoS protection. Configured via our Cloudflare tooling to standardize cache rules, security headers, and page rules.

Deployment pipeline

The daily workflow:

1. Local development with wp-env or Lando.
2. Push to feature branch on GitHub.
3. Railway detects the push and builds the Docker image automatically.
4. If the branch is main, Railway deploys to production with rolling update (zero downtime).
5. If it’s another branch, Railway creates a preview environment with a unique URL.
6. Post-deploy: Redis cache flush, rewrite flush, Cloudflare cache warming.

Step 6 is automated with a post-deploy script that Railway runs via the deploy.startCommand field. The same script we use manually with our deploy tools runs automatically.

Result: a WordPress theme change goes from commit to production in 3-4 minutes, with zero downtime and instant rollback if anything fails (Railway retains the last 5 deployed images).

Railway vs traditional hosting

An honest comparison based on real costs from our deployments:

Criterion	Shared hosting	Managed VPS	Managed WP (Kinsta)	Railway
Monthly cost (1 site)	EUR 10-20	EUR 30-80	EUR 100-300	EUR 15-40
Deployment	FTP / Git pull	SSH + scripts	Dashboard + Git	Git push
Deploy downtime	Variable	Seconds	Seconds	Zero
Staging	Manual / None	Manual	Included	Automatic (preview envs)
Scaling	No	Vertical	Limited	Horizontal
Backups	Daily (hosting)	Manual or cron	Included	Automatic
SSL	Let’s Encrypt	Let’s Encrypt	Included	Automatic
Reproducibility	Low	Medium	Low	High (Docker)

Railway isn’t the cheapest for a simple site. Shared hosting at EUR 10/month works perfectly for a blog with 5,000 monthly visits. Where Railway wins is everything else: professional development workflow, reliable deployments, automatic staging environments, and the ability to manage multiple sites with the same architecture.

Railway vs Kubernetes

Kubernetes can do everything Railway does and far more. But the operational cost isn’t comparable.

An EKS cluster (AWS) serving 3 WordPress sites costs a minimum of EUR 150-200/month in infrastructure alone, plus the cost of the DevOps engineer managing it. Railway for the same 3 sites costs EUR 50-120/month and doesn’t need a dedicated DevOps person.

Kubernetes makes sense when:

• You manage 50+ services with complex orchestration requirements.
• You need granular control over networking, scheduling, and resource limits.
• Your team has K8s experience and capacity to maintain it.

For 3-20 web services (WordPress, Next.js, APIs), Railway delivers 90% of K8s benefits with 10% of the complexity.

Next.js on Railway: the other half

Railway isn’t just WordPress. Next.js deployed on Railway is where the platform shines brightest, because the deployment model naturally aligns with the framework.

For sites like our Next.js applications, the stack is:

• Next.js 15 with App Router.
• PostgreSQL database managed on Railway.
• Redis for sessions and cache.
• Environment variables managed by Railway (no .env files in production).

Deployment is identical to WordPress: git push to main, Railway builds, Railway deploys. The advantage over Vercel (the natural alternative for Next.js) is that Railway lets you deploy the database, cache, and application on the same platform, with private networking between services. On Vercel you need an external database (Supabase, PlanetScale, Neon), which adds latency and another provider to manage.

Cost comparison: Vercel Pro costs $20/month per team member plus the cost of an external database. Railway charges for what you consume, typically $15-40/month for a Next.js app with database included.

Lessons learned

18 months of production taught us these things (some the hard way):

The build must be deterministic or you’ll pay for it. If your Dockerfile uses latest tags or installs dependencies without a lockfile, two builds of the same commit can produce different results. We pin versions for everything: base image, PHP dependencies (composer.lock), Node dependencies (package-lock.json).

Persistent volumes are not backup. A Railway persistent volume survives a redeployment but not an accidental service deletion. Critical uploads go to Cloudflare R2 with versioning enabled. Lesson learned from a scare (not a loss, fortunately).

Cloudflare cache is essential. Without CDN caching, every visit to a WordPress site on Railway consumes container CPU. With Cloudflare caching full pages for anonymous visitors, 85-90% of traffic never touches the container. This drastically reduces cost and improves TTFB to < 50ms for cached content.

Monitor consumption from day one. Railway bills by usage. A WordPress plugin that fires a cron every minute (yes, we’ve seen this) can generate an unexpected bill. We configure consumption alerts in Railway and review billing weekly.

Team onboarding is fast. A WordPress developer who has never touched Docker can be deploying on Railway within a day. The learning curve is significantly lower than K8s, and the mental model (push to deploy) is familiar to anyone who has used Heroku.

When Railway isn’t the answer

Not everything should go on Railway. Scenarios where we look elsewhere:

• Pure static sites. Cloudflare Pages or Vercel. Free, faster, simpler.
• Applications with strict compliance requirements (health data, regulated finance). Railway doesn’t offer specific regions or SOC 2/HIPAA certifications. In those cases, AWS or GCP with custom configuration.
• Applications with massive, predictable traffic spikes (Black Friday, events). Railway scales, but doesn’t have custom-metric-based auto-scaling like K8s with HPA. For extreme spikes, pre-scale manually or use a platform with native auto-scaling.

For everything else, for the 90% of websites and applications we build and manage, Railway offers the right balance of simplicity, cost, and control. It’s not magic. It’s engineering well abstracted. If your team does not have a dedicated DevOps person, our guide to CI/CD for small teams complements this architecture.