Deploy WordPress Multisite

Run a network of WordPress sites from one install

Deploy WordPress Multisite

Just deployed

/var/lib/mysql

Just deployed

/var/www/html

Deploy and Host self hosted WordPress Multisite (WordPress Multisite Network on One Install) on Railway

This template turns one self-hosted WordPress install into a multisite network for many sites with shared plugins and users.

About Hosting WordPress Multisite open-source software on Railway (self hosted WordPress Multisite template)

This template runs WordPress 7.1.3 on PHP 8.4 with Apache, backed by MariaDB 12.3.3 for content and Valkey 9.1.2 as the object cache.

Multisite adds one decision to make early.

Why Deploy WordPress Multisite, the WordPress VIP alternative on Railway (Railway Free Trial)

WordPress VIP suits enterprise budgets, and Railway gives you one network of sites with shared plugins and users at a fraction of that cost.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying WordPress Multisite on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for WordPress Multisite self hosting

Railway runs the WordPress, MariaDB and Valkey services for you, while a VPS leaves the stack and network setup to you.

ProviderWhat You Get with RailwayWhat You Get with the Other Provider
DigitalOceanLinked services, volumes and a wildcard custom domain, with no server to patchA Droplet you set up yourself, including wildcard DNS and WP-CLI
AWSOne project and one bill, with no VPC or security group workFull control over EC2 and RDS, but you build the multisite wiring yourself
HetznerDashboard deploys and redeploys, with no SSH needed to add constantsLow-cost servers with plenty of RAM, but all the setup is manual

Choose Railway for a fast start and a VPS when you need full server control.

Common Use Cases for hosted WordPress Multisite

  • Agency client microsites: Run one network for a dozen client sites, each with its own admin, theme and content, while you manage the shared plugins and updates from one place.
  • School or university departments: Give each department its own site under one network, so faculty can publish their own pages without you maintaining twelve separate installs.
  • Regional or language sites: Serve a company's country or language versions from one install, with a shared media library and users who can move between sites.
  • Landing page networks: Spin up a new campaign or product landing page as a fresh site in minutes, reusing the same theme and plugin set.
  • Shared plugin and theme management: Install and update plugins and themes once for the whole network, and network activate only the ones every site needs.

Dependencies for WordPress Multisite Docker hosted on Railway

This stack runs three services: a WordPress container built from ghcr.io/onepush-dev/wordpress:7.1.3-php8.4, a MariaDB 12.3.3 database, and a Valkey 9.1.2 cache.

Deployment Dependencies for Managed WordPress Multisite Service (CMS)

  • MariaDB: version 12.3.3 with a volume at /var/lib/mysql and MARIADB_INNODB_BUFFER_POOL_SIZE tuned.
  • Valkey: version 9.1.2, password protected, capped at 256mb with no volume, since it is only a cache.

Implementation Details for WordPress Multisite (Using WordPress official docker image)

  • Image: WordPress 7.1.3 on PHP 8.4 with Apache, OPcache at 256 MB, and the Redis Object Cache drop-in.
  • Database variables: WORDPRESS_DB_HOST, WORDPRESS_DB_NAME, WORDPRESS_DB_USER and WORDPRESS_DB_PASSWORD reference MariaDB, and WORDPRESS_CONFIG_EXTRA holds the multisite constants.
  • Cache variables: WP_REDIS_HOST, WP_REDIS_PORT and WP_REDIS_PASSWORD reference Valkey.
  • PHP limits: PHP_MEMORY_LIMIT 512M, PHP_UPLOAD_LIMIT 256M and PHP_MAX_EXECUTION_TIME 300.

How does WordPress Multisite compare against other ways to run many WordPress sites

Running many sites is a choice between a few models, and each has a clear winner for some job.

WordPress Multisite vs separate installs (Separate WordPress Installs)

  • Shared maintenance: One core update, one plugin set and one database cover every site, so you patch once instead of ten times.
  • Isolation: Separate installs keep each site fully apart, so a broken plugin on one cannot touch another. Multisite shares plugins and users, which is the trade for less upkeep.
  • Footprint: One MariaDB and one Valkey serve the whole network here, while separate installs each need their own.

WordPress Multisite vs WordPress VIP (WordPress VIP Alternative)

  • Control: WordPress VIP is an enterprise managed platform with support contracts and strict code review. This template is self-hosted on Railway, so you own the server.
  • Support: VIP wins clearly if you need a vendor on call at 2 a.m. You get no such guarantee here.
  • Multisite fit: Both can run a network, but here you set the domain and constants yourself, which is more work and more freedom.

WordPress Multisite vs WP Engine (WP Engine Alternative)

  • Managed care: WP Engine handles updates, backups and caching for you, and its higher plans include multisite. This template leaves those jobs to you.
  • Tuning: This stack ships OPcache, the Redis Object Cache drop-in and tuned MariaDB out of the box.
  • Cost model: WP Engine is plan based with a fixed monthly bill. Here you pay Railway usage, which is cheaper for small networks.

WordPress Multisite vs a headless CMS (Headless CMS Alternative)

  • Architecture: A headless CMS such as Strapi or Payload serves content through an API with a separate front end. Multisite keeps theme and front end in one place.
  • Developer effort: A headless CMS needs more build work. Multisite gets sites live faster with classic WordPress themes and plugins.
  • Flexibility: A headless setup wins when you want a custom front end on every site, since it frees you from WordPress themes entirely.

How to use WordPress Multisite (the OSS content management system)?

Work through these steps once the deploy finishes and the standard installer is done.

  1. Add your final custom domain and set WP_HOME to https://your-domain if you are leaving the Railway domain, because changing it later means a database search-replace.
  2. Back up the database.
  3. Deactivate all plugins.
  4. Add define( 'WP_ALLOW_MULTISITE', true ); to WORDPRESS_CONFIG_EXTRA and redeploy.
  5. Open Tools, Network Setup and choose subdirectories, which work on the Railway domain.
  6. Copy the constants WordPress shows into WORDPRESS_CONFIG_EXTRA and redeploy.
  7. Replace the rules in /var/www/html/.htaccess with the multisite rules WordPress shows.
  8. Log in again, then add a site under My Sites, Network Admin, Sites.
WORDPRESS_CONFIG_EXTRA=define( 'WP_ALLOW_MULTISITE', true ); define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', false ); define( 'DOMAIN_CURRENT_SITE', 'your-domain' ); define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 );

wp site create --slug=blog --title="Blog"

How to self host WordPress Multisite on other VPS Services (WordPress self hosting guide)

Running this on your own VPS means a plain WordPress image plus MariaDB and an optional Valkey cache.

Clone the Repository

Pull the template source and move into the folder. The WordPress image is pinned by digest.

git clone https://github.com/onepush-dev/wordpress.git your-domain-wp
cd your-domain-wp

Install Dependencies

You need Docker and a DNS record pointing at the server.

Configure Environment Variables

Set the final domain first, because changing a network domain later means a database search-replace.

WP_HOME=https://your-domain
WORDPRESS_CONFIG_EXTRA="define( 'WP_ALLOW_MULTISITE', true );"

Add the constants WordPress shows after Network Setup, then redeploy.

Start the WordPress Multisite Application

Bring the stack up, finish the installer, then run Tools, Network Setup and paste the .htaccess rules into /var/www/html.

Official Pricing of WordPress Multisite (WordPress pricing)

WordPress Multisite is free and open source under GPLv2, so there is no license fee to pay.

WordPress Multisite cloud vs self hosted comparison (Pricing, features, costs, and more)

Running WordPress Multisite on Railway means you pay for three small services instead of a managed plan, so the trade-off is cost and control against convenience.

Monthly cost of self hosting WordPress Multisite on Railway

Railway bills by usage, and a small to medium network typically lands around $5 to $20 per month, depending on traffic and how much RAM the WordPress and MariaDB services use.

System Requirements for Hosting WordPress Multisite on a VPS

For a small network, plan on roughly 512 MB to 1 GB of RAM for WordPress plus MariaDB, and keep Valkey capped at 256 MB.

Frequently Asked Questions (FAQs)

Should I use subdirectories or subdomains on Railway?

Use subdirectories unless you have a custom domain with wildcard DNS.

Can I change the network domain later?

Technically yes, but it means a database search and replace across the network tables and content.

Does the Redis object cache work per site?

Yes. All sites share the one 256 MB Valkey instance, so a busy network can evict entries sooner.

Are plugins and themes shared across the network?

Plugins and themes are installed once for the whole network.

Do I need wildcard DNS?

Only for subdomain networks.

How do I undo multisite?

Back up the database first, then remove the multisite constants and WP_ALLOW_MULTISITE from WORDPRESS_CONFIG_EXTRA, restore the standard WordPress .htaccess rules, and redeploy.


Template Content

More templates in this category

View Template
Libredesk - Complete Setup
Complete self-hosted omnichannel customer support desk.

codestorm
2
View Template
Paperless-ngx
Paperless-ngx — document management with OCR and full-text search

INAPP
1
View Template
Instatic CMS - Postgres
Design, build and manage powerful static sites from state-of-the-art CMS

Instatic
167