WordPress Multisite Hosting: Server Setup and Management Guide

WordPress Multisite is a single WordPress installation that powers multiple distinct sites from one database and codebase. Hosting it correctly is fundamentally different from hosting a standard WordPress install — resource contention, domain routing, and database architecture all require deliberate configuration decisions before you spin up a single sub-site.

What Makes WordPress Multisite Hosting Different From Standard Hosting?

The core difference is that a single application failure affects every site on the network simultaneously. Standard WordPress hosting treats each install as an isolated unit. Multisite collapses that isolation by design — which means server-level safeguards must compensate. You're also dealing with a more complex URL routing layer and a shared plugin/theme filesystem that complicates updates.

For a thorough breakdown of Multisite's feature set and admin workflow, see the WordPress Multisite: Complete Setup and Management Guide — this post focuses exclusively on the hosting and infrastructure layer.

Server Requirements for WordPress Multisite

Minimum viable server spec assumes you're running 10 or fewer sub-sites with moderate traffic. For production agency or enterprise deployments, treat these as hard floors, not targets.

PHP memory per worker should be set to at minimum 256 MB (memory_limit = 256M), with max_execution_time = 60. WordPress Multisite's cron system runs network-wide jobs that can hit timeout limits on smaller values.

According to W3Techs, WordPress powers 43.5% of all websites (2024), and a significant proportion of high-site-count deployments are Multisite networks — meaning the hosting market has benchmarked these requirements extensively. Don't underspec.

Subdomain vs Subdirectory: The Hosting Implications

Choose subdomain networks for production agencies or SaaS platforms; choose subdirectory networks for simpler deployments where portability isn't a concern. The choice is permanent without a migration — it's baked into your WordPress configuration.

Subdomain Networks

• Require wildcard DNS: *.yourdomain.com → server IP
• Require wildcard SSL certificate (Let's Encrypt supports wildcard via DNS-01 challenge only)
• Each sub-site resolves as site1.yourdomain.com, site2.yourdomain.com
• Custom domain mapping (e.g., client.com pointing to site1.yourdomain.com) requires additional DNS configuration per site and your hosting layer must handle SERVER_NAME matching

Subdirectory Networks

• Standard SSL covers the root domain + all paths
• Simpler NGINX/Apache rewrite rules
• Migration to a standalone install is harder — paths are embedded in the database
• Cannot be used on an existing WordPress install that already has posts

For wildcard SSL provisioning without the manual DNS-01 challenge headache, managed hosting platforms that automate certificate issuance are worth the cost — this is one of the friction points that consumes hours in a self-managed environment. The WordPress SSL & HTTPS setup guide covers certificate types and Let's Encrypt configuration in detail.

NGINX Configuration for WordPress Multisite

Standard WordPress NGINX configs break on Multisite because permalink rewriting must account for sub-sites. Here's a production-hardened configuration block for a subdirectory network:

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    root /var/www/html;
    index index.php;

    # Multisite subdirectory rewrite rules
    if (!-e $request_filename) {
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;
        rewrite ^(/[^/]+)?(/wp-.*) $2 last;
        rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_read_timeout 60;
    }

    # Uploaded files: serve from network uploads directory
    location ~* ^/files/(.+) {
        try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 =404;
        access_log off;
        expires max;
    }
}

For a subdomain network, replace the rewrite section with:

server_name ~^(?<subdomain>.+)\.yourdomain\.com$;

And ensure your wildcard DNS record is in place before testing. NGINX will return a 404 on any new sub-site if wildcard DNS hasn't propagated — a common gotcha that looks like a WordPress problem but is a DNS problem.

PHP-FPM Pool Isolation

Running all sub-sites under a single PHP-FPM pool is the most common Multisite hosting mistake. A single site running a memory-intensive import, a WooCommerce bulk operation, or a poorly coded plugin can exhaust all available PHP workers and queue-block every other site on the network.

The solution is separate PHP-FPM pools per site (or per site group for large networks):

; /etc/php/8.3/fpm/pool.d/site1.conf
[site1]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm-site1.sock
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests = 500

Point each sub-site's NGINX fastcgi_pass to its dedicated socket. This adds configuration overhead but gives you per-site resource caps and prevents cascade failures. On managed infrastructure like TopSyde's hosting plans, this pool isolation is handled at the platform level — you don't configure it per-site manually.

Database Architecture: Shared Tables vs Separate Databases

WordPress Multisite uses a shared database with prefixed tables per sub-site by default. Site 1 gets wp_posts, site 2 gets wp_2_posts, site 3 gets wp_3_posts. The wp_blogs, wp_site, wp_users, and wp_usermeta tables are global.

This works well up to roughly 50–100 sites. Beyond that, you'll encounter:

• Table count bloat (a 100-site network has 900+ tables with default schema)
• wp_users and wp_usermeta becoming query bottlenecks at scale
• Backup granularity problems — you can't restore a single site without restoring the whole database

For networks above 50 sites, evaluate the HyperDB drop-in or a custom db.php that routes per-site table reads to separate database instances. This is a non-trivial architectural change but it's the right move for high-traffic SaaS-style deployments.

Index your wp_usermeta table on (user_id, meta_key) — the default index is user_id only, and Multisite's capability checks hit meta_key repeatedly:

ALTER TABLE wp_usermeta ADD INDEX meta_key_lookup (user_id, meta_key);

According to Kinsta's WordPress benchmarks, uncached database queries are the primary bottleneck in 70%+ of slow WordPress sites — Multisite amplifies this because global table queries run on every page load across every sub-site.

Object Caching: Redis Is Non-Negotiable at Scale

Without a persistent object cache, every page load on every sub-site hits MySQL for user capabilities, site options, and transients. At 10+ sites with moderate traffic, this will saturate your database.

Install the Redis Object Cache plugin (or the Predis-based drop-in), then configure wp-config.php at the network level:

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
// Key prefix prevents cache collision between sub-sites
define('WP_REDIS_PREFIX', 'ms_' . DB_NAME);

For subdomain networks where each sub-site is a separate HTTP context, the object cache key prefix must include the blog ID. The Redis Object Cache plugin handles this automatically, but verify it in the plugin's diagnostic screen — cache key collisions between sub-sites are subtle and manifest as wrong content appearing on the wrong site.

Allocate at minimum 256 MB of Redis memory for a 10-site network; 1 GB for 50+ sites. Set maxmemory-policy allkeys-lru to prevent Redis from refusing writes when memory fills.

Custom Domain Mapping

Custom domain mapping lets a sub-site at site3.yourdomain.com respond to client-brand.com. The server-side requirements are:

1. client-brand.com DNS A record points to your server IP
2. NGINX server_name must match client-brand.com — either list it explicitly or use a catch-all with domain-to-blog-ID lookup via the Sunrise drop-in
3. SSL certificate must cover client-brand.com — this means individual Let's Encrypt certificates per mapped domain, not a wildcard

The WordPress MU Domain Mapping plugin (now superseded by core Multisite domain mapping in WP 4.5+) can manage the database side. The server side requires a catch-all NGINX server block:

server {
    listen 443 ssl http2;
    server_name _;  # catch-all
    ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;
    # ... rest of config
}

Automating certificate issuance for arbitrary mapped domains requires scripting certbot certonly --webroot or using a platform that handles this natively. This is operationally expensive to self-manage at scale — for agencies running 20+ mapped domains, the cert renewal alone becomes a maintenance burden. The managed hosting for marketing agencies post covers how agency-focused hosting platforms handle this at the infrastructure level.

Scaling: When to Move Beyond Single-Server Multisite

A single optimized server can handle most Multisite deployments up to ~200 concurrent users across the network. Beyond that, horizontal scaling introduces new constraints:

• Shared filesystem: /wp-content/uploads must be accessible from all web nodes. Use NFS, GlusterFS, or offload to S3 with a plugin like WP Offload Media
• Sticky sessions vs stateless: PHP sessions must be centralized (Redis session handler) or eliminated — don't use default file-based sessions
• Centralized cron: wp-cron will fire on every node. Disable it (define('DISABLE_WP_CRON', true)) and run a single server-side cron via WP-CLI:

*/5 * * * * www-data /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet

For multi-node Multisite deployments, the architecture starts resembling a full SaaS infrastructure. The WordPress Multi-Tenancy architecture guide covers the patterns in depth — including when Multisite stops being the right tool entirely and purpose-built multi-tenancy frameworks become appropriate.

Multisite vs Separate Installs: When to Choose Each

Agencies managing large fleets of independent client sites typically get better operational results from separate installs with a structured agency workflow than from a Multisite network — the shared failure domain is a real liability in client-facing hosting.

Managed Hosting for Multisite Networks

Self-managing the infrastructure described above — PHP-FPM pools, Redis, wildcard SSL, domain mapping automation, per-site backup — is viable but expensive in engineering time. TopSyde's managed WordPress hosting starts at $89/mo and handles the Multisite-specific infrastructure layer: wildcard certificate provisioning, Redis object caching, PHP-FPM pool configuration, and automated backups with per-site restore granularity.

For agencies evaluating whether to self-host or delegate infrastructure, the WordPress Hosting for Freelancers guide has an honest breakdown of the time costs involved — the same calculus applies to small agency teams. See the full hosting spec sheet for Multisite-specific configuration details.

Frequently Asked Questions

Can WordPress Multisite run on shared hosting?

Technically yes, but practically no for any production deployment. Shared hosting enforces global PHP-FPM limits, restricts wildcard DNS configuration, and typically blocks Redis. The first time a neighboring tenant saturates the server, every site on your network goes down simultaneously. Multisite requires a VPS or managed hosting environment at minimum.

How many sites can WordPress Multisite support?

With proper server configuration — dedicated PHP-FPM pools, Redis object caching, and an optimized MariaDB instance — a single server can support 50–200 active sub-sites depending on traffic patterns. Beyond 200 sites or high-concurrency workloads, you need database sharding or horizontal scaling. WordPress.com runs Multisite at millions of sites, but that architecture bears no

Marcus Webb

DevOps & Security Lead

12+ years DevOps, Linux & cloud infrastructure certified

Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.

XLinkedIn