Deploy and Host WordPress on Railway

WordPress is the content management system behind a large share of the web: pages, posts, themes, 59,000+ plugins, a REST API, and a media library. This template runs WordPress 6.9.1 on PHP 8.3 with MariaDB 11.8, both on their own volumes, and it hands you a site that is already installed with an administrator account of its own — nothing to claim, nothing to finish in a setup wizard that the whole internet can reach.

About Hosting WordPress

Hosting WordPress means running PHP against a MySQL-compatible database, keeping the uploads directory and the plugin/theme tree on durable storage, and putting the login page on the public internet. On a platform that redeploys containers, three details decide whether the result is safe and whether it keeps working:

The install screen is the front door. A freshly deployed WordPress serves /wp-admin/install.php to whoever arrives first, and that visitor becomes an administrator. The URL exists before you open it.
The client address is not what the container sees. Railway terminates TLS at its edge and reaches the container from an address that changes between requests, so anything keyed on REMOTE_ADDR — comment records, security plugins, rate limits — is recording a proxy hop rather than a visitor.
Everything mutable lives in one directory. wp-content holds uploads, plugins and themes, and wp-config.php holds the keys that sign every session cookie. Without a volume mounted at the web root, a redeploy takes them all.

This template settles all three before the first request is served: WordPress is installed and the administrator seeded while Apache is still stopped, the real visitor address is restored from the forwarding header for every plugin that reads it, failed logins are throttled per client, and /var/www/html and /var/lib/mysql each sit on a volume.

Why Deploy WordPress on Railway?

Railway gives WordPress a private network to reach MariaDB on, volumes for the web root and the database, TLS on a public domain, and usage-based billing rather than a fixed plan. The template is two services and no manual steps: deploy it, read the generated administrator password out of the service variables, and log in.

Common Use Cases

Business sites and blogs — the standard WordPress install, themes and plugins included, with uploads that survive a redeploy.
Headless content API — the built-in REST API in front of a React, Next.js or mobile front end.
WooCommerce and membership sites — a full LAMP-style stack where the database and the uploads directory each have their own persistent volume.

Dependencies for WordPress Hosting

MariaDB 11.8 (included in this template, on its own volume)
PHP 8.3 with the official WordPress image's extension set
A volume mounted at /var/www/html

Deployment Dependencies

Implementation Details

Logging in. The administrator is created at first boot with the password in the WORDPRESS_ADMIN_PASSWORD variable on the wordpress service (generated for your deploy). The user is admin. The password is re-applied on every boot, so changing that variable and redeploying rotates it — useful, because WordPress has no other recovery path when outbound mail is not configured.

Login throttle. Ten failed logins per client address in fifteen minutes, then HTTP 429 until the window passes. Tune with WORDPRESS_LOGIN_MAX_ATTEMPTS and WORDPRESS_LOGIN_WINDOW. WordPress core ships no throttle at all.

XML-RPC. xmlrpc.php is blocked at Apache and disabled inside WordPress, because system.multicall lets a single request carry many credential guesses. Set WORDPRESS_ENABLE_XMLRPC=1 if you need Jetpack or the WordPress mobile apps.

Custom domains. The site URL follows RAILWAY_PUBLIC_DOMAIN by default. When you point a custom domain at the service, set WORDPRESS_SITE_URL=https://your-domain so links, redirects and asset URLs follow it.

Uploads and memory. The upload limit is 64 MB (WORDPRESS_UPLOAD_MAX_MB) and PHP's memory limit is sized from the container's own cgroup rather than the stock 128 MB, so a larger plan is actually used.

Backups. MariaDB's data directory is on a volume; use Railway's volume backups, or a WordPress backup plugin writing to object storage, before major plugin or core upgrades.