Railway and Modern PaaS: WordPress Deployments That Scale

The problem with traditional hosting

Most production WordPress sites follow the same path: they start on shared hosting, move to a VPS when shared hosting falls short, and end up on a dedicated server or managed WordPress hosting (Kinsta, WP Engine).

Every move is a manual migration that’s easy to get wrong. Backups depend on a cron job or on someone remembering. Scaling is vertical: when you need more power, you buy a bigger server. And deploying changes usually means an FTP upload or a git pull on the server.

For a corporate site or a landing page, this works. It breaks when you need more: several environments (staging and production), atomic zero-downtime deployments, horizontal scaling under load, or a team looking after 5 to 10 sites while the operating cost multiplies.

Kubernetes solves all of that, at the price of a lot of complexity. Running a cluster to serve WordPress makes sense for few organisations; for most, the cost of operating it outweighs the benefit.

That gap is where modern PaaS sits, and Railway is one of the most direct options for small teams.

What Railway is (and isn’t)

Railway is an infrastructure platform that abstracts away servers, networking and orchestration. It takes code (from a Git repository or a Dockerfile), builds it, deploys it and keeps it running. It uses containers internally, but you don’t need to master Docker to start.

It isn’t a WordPress host: there’s no cPanel and no one-click installer. It’s a platform for anything that runs in a container: WordPress with PHP-FPM and Nginx, Next.js, Python APIs, MySQL or PostgreSQL databases, Redis, or a search engine like Meilisearch.

The core difference from traditional hosting is that the infrastructure is described in configuration: it deploys with a git push and can be reproduced in another project in minutes.

Reference architecture for WordPress on Railway

A sensible architecture for a business WordPress site on Railway has five parts.

WordPress service. A container with its own image: PHP 8.3 with FPM, Nginx as the web server and WP-CLI installed. The theme and custom plugins live in Git; third-party plugins are managed with Composer (via wpackagist). With pinned versions, the same commit always produces the same image.

MySQL. A database service in the same project, on the private network. Turn on periodic backups and test from time to time that they actually restore. For large volumes, WordPress can point to an external database.

Redis. Object cache through the Redis Object Cache plugin. It takes load off MySQL, and on WooCommerce stores with large catalogues it’s one of the most noticeable improvements in response time.

Persistent volume. For wp-content/uploads. Railway mounts persistent volumes on the service. When the media library grows large, the usual alternative is S3-compatible object storage through a plugin such as WP Offload Media.

A cache in front. A CDN or caching proxy that serves full pages to anonymous visitors. Without that layer every visit uses container CPU, and on a platform that bills by usage, you pay for it.

Deployment flow

The daily flow looks like this:

1. Local development with wp-env or Lando.
2. Push to a branch on GitHub.
3. Railway detects the push and builds the image.
4. If the branch is main, it deploys to production with no downtime: the new container comes up before the old one is retired.
5. For any other branch, you can create a preview environment with its own URL.
6. After the deploy: flush the object cache and rewrite rules, and warm the page cache.

Step 6 is automated with a script that runs when the service starts. With this in place, a theme change goes from commit to production in a few minutes, and if something fails you roll back to the previous deployment from the dashboard.

Railway vs traditional hosting

Criterion	Shared hosting	Managed VPS	Managed WordPress	Railway
Cost for one site	Low	Medium	High	Low to medium, by usage
Deployment	FTP or git pull	SSH and scripts	Dashboard and Git	Git push
Downtime on deploy	Variable	Seconds	Seconds	None when configured well
Staging	Manual or none	Manual	Included	Per-branch environments
Scaling	No	Vertical	Limited	Vertical and replicas
Backups	The provider’s	Manual or cron	Included	Configurable per service
SSL	Let’s Encrypt	Let’s Encrypt	Included	Automatic
Reproducibility	Low	Medium	Low	High (containers)

Railway isn’t the cheapest option for a simple site: a low-traffic blog runs fine on shared hosting. Where it pays off is everything else: a professional workflow, reliable deployments, automatic test environments and the ability to run several sites on the same architecture.

Railway vs Kubernetes

Kubernetes does everything Railway does and much more, but its operating cost isn’t comparable. A managed cluster (EKS, GKE, AKS) charges for the control plane and the nodes even when the sites get little traffic, and someone on the team has to maintain it.

Kubernetes makes sense when:

• there are dozens of services with complex orchestration needs;
• you need fine control over networking, scheduling and resource limits;
• the team already has Kubernetes experience and time to maintain it.

For a handful of web services (WordPress, Next.js, APIs), a PaaS like Railway covers most of those benefits with far less operations work.

Next.js on Railway

Railway isn’t only for WordPress. Next.js fits its deployment model well. A typical stack:

• Next.js with the App Router.
• PostgreSQL in the same project.
• Redis for sessions and cache.
• Environment variables managed by the platform, with no .env files in production.

Deployment works the same as for WordPress: push to main, build, deploy. Compared with Vercel, the natural alternative for Next.js, the difference is that on Railway the database, the cache and the application live on the same platform with private networking between them. On Vercel the database is usually an external provider (Supabase, Neon and the like), which adds one more provider to manage.

On cost, Vercel charges its Pro plan per team member, with the database billed separately; Railway bills by usage. Which one comes out cheaper depends on team size and traffic, so work it out with both providers’ current prices.

Good practices

Deterministic builds. If the Dockerfile uses latest tags or installs dependencies without a lockfile, two builds of the same commit can produce different results. Pin everything: base image, PHP dependencies (composer.lock) and Node dependencies (package-lock.json).

A volume is not a backup. A persistent volume survives a redeploy but not the deletion of the service. Critical files need a copy outside the platform, ideally with versioning.

Always cache in front. With pages for anonymous visitors served from cache, most traffic never reaches the container: usage drops and response times improve.

Watch usage from day one. Railway bills by usage. A plugin that fires a cron job every minute can drive the bill up. Set spending limits and alerts, and review usage regularly.

A short learning curve. A WordPress developer who has never used Docker can be deploying on Railway quickly. The mental model (push to deploy) is familiar to anyone who has used Heroku.

When Railway isn’t the answer

• Purely static sites. Static hosting platforms such as Cloudflare Pages or Netlify are simpler and usually have a free tier that’s enough.
• Strict compliance requirements (health data, regulated finance, data residency). Before choosing, check Railway’s security documentation for its current certifications and regions and whether they cover your case. If not, AWS, GCP or your own servers with a tailored setup.
• Extreme traffic spikes. Railway supports replicas, but autoscaling on custom metrics is more limited than Kubernetes with HPA. For very large spikes, scale up ahead of time or use a platform with native autoscaling.

For other websites and mid-sized applications, Railway strikes a good balance between simplicity, cost and control. If your team has nobody dedicated to DevOps, the guide to CI/CD for small teams complements this architecture.