WordPress Multisite on Managed Hosting: Platform-Specific Configuration, Limitations, and Workarounds
Why Multisite on Managed Hosting Demands Platform-Specific Knowledge
WordPress Multisite transforms a single WordPress installation into a network capable of running dozens, hundreds, or even thousands of sites from one codebase. For agencies managing client portfolios, universities running departmental sites, or enterprises consolidating web properties, multisite offers genuine operational advantages: centralized updates, shared user management, and reduced server overhead compared to maintaining separate installations.
But running multisite on managed hosting platforms introduces a category of problems that standard WordPress documentation simply does not address. Each managed host imposes its own constraints on server configuration, file system access, caching layers, and deployment workflows. What works on WP Engine will break on Pantheon. What Kinsta handles automatically requires manual intervention on Cloudways. The configuration files that Flywheel expects differ from what any other platform requires.
I have spent the better part of a decade deploying multisite networks on every major managed hosting platform, and the pattern is always the same: teams assume that enabling multisite is the hard part, only to discover that the real complexity lives in platform-specific edge cases that surface weeks or months after launch. DNS propagation failures that only affect subdomain networks on certain hosts. Object cache key collisions that corrupt data across subsites. Backup systems that cannot isolate individual sites within a network. Push-to-live deployment workflows that silently break domain mappings.
This article covers the practical, platform-specific knowledge required to run WordPress Multisite on WP Engine, Pantheon, Kinsta, Flywheel, and Cloudways. Every configuration example, CLI command, and workaround comes from production deployments. Nothing here is theoretical.
Plan Requirements: What You Actually Need to Buy
Not every hosting plan supports multisite. Most managed hosts restrict multisite to higher-tier plans, and the specific tier matters because it determines resource allocations, support access, and available features.
WP Engine: Growth Plan and Above
WP Engine requires the Growth plan or higher for multisite support. The Startup plan explicitly excludes multisite. On Growth, you get support for up to 10 sites within a single multisite network. The Scale plan raises this to 30 sites, and custom enterprise plans can go higher.
A critical detail that WP Engine’s marketing materials gloss over: the “sites” count on Growth and Scale plans refers to the total across all environments. If you maintain staging and development environments (and you should), each environment with multisite enabled counts against your site allocation. A 10-site multisite network with staging and development environments effectively consumes 30 site slots.
Pantheon: Gold Plan and Above (Performance Tier)
Pantheon supports multisite on Gold and above within their Performance site plans. Their Basic plan does not support multisite at all. Pantheon also restricts multisite to subdirectory installations on their standard infrastructure. Subdomain multisite requires custom domain configuration per subsite through their platform dashboard, and each custom domain counts against your plan’s domain limit.
Pantheon’s pricing model is traffic-based rather than site-count-based, which changes the economics. A multisite network with 50 low-traffic subsites may cost less than you would expect, but a network with even 5 high-traffic subsites can push you into expensive overage territory quickly.
Kinsta: Business Plan and Above
Kinsta requires the Business plan or higher for multisite. Their Starter and Pro plans do not support it. On Business, you get one WordPress installation that can run as a multisite network. Each additional multisite network counts as a separate site install against your plan’s allocation.
Kinsta charges per “WordPress install,” and a multisite network counts as one install regardless of the number of subsites. This makes Kinsta one of the more cost-effective options for large multisite networks. However, resource limits (PHP workers, disk space, bandwidth) are still tied to the plan level, and a busy multisite network will consume these faster than a single site.
Flywheel: Freelance Plan and Above
Flywheel supports multisite on the Freelance plan and above. Their Tiny and Starter plans do not include multisite capability. Flywheel’s pricing for multisite is straightforward: the base plan price covers the multisite installation, but resource limits apply to the aggregate network, not to individual subsites.
This aggregate model is important to understand. If your Freelance plan includes 25,000 monthly visits, that is 25,000 visits across all subsites combined, not per subsite. Agencies that host multiple client sites on a single Flywheel multisite network frequently hit resource ceilings faster than expected.
Cloudways: Any Plan (Self-Managed)
Cloudways is the outlier in this list because it is a managed infrastructure provider rather than a managed WordPress host. Multisite is available on any Cloudways plan because you have server-level access to configure it yourself. The trade-off is that Cloudways provides no multisite-specific tooling, support, or guardrails. You get a server, a WordPress installation, and the freedom to configure multisite however you want.
For teams comfortable with server administration, Cloudways offers the most flexibility. For teams that want managed multisite support, it demands the most work.
Subdomain vs. Subdirectory: Platform-Specific SSL and DNS Requirements
The choice between subdomain multisite (site1.example.com, site2.example.com) and subdirectory multisite (example.com/site1, example.com/site2) is not purely a matter of URL preference. Each managed hosting platform handles the SSL certificate provisioning and DNS requirements for these two modes differently, and the wrong choice can create problems that are expensive to reverse.
Subdirectory Mode: The Path of Least Resistance
Subdirectory multisite is simpler on every managed platform because it requires only a single domain and a single SSL certificate. All subsites share the root domain’s DNS records and certificate. On WP Engine, Pantheon, Kinsta, and Flywheel, subdirectory multisite works with standard configuration and no additional DNS or SSL setup beyond the primary domain.
The relevant wp-config.php constants for subdirectory mode:
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );The main limitation of subdirectory mode is that WordPress only supports it on fresh installations or installations where the site has existed for less than 30 days. If you have an established single-site WordPress installation that has been live for more than a month, WordPress will only offer subdomain mode during the multisite network setup. You can override this restriction by manually setting SUBDOMAIN_INSTALL to false, but doing so on a site with existing content can create permalink conflicts.
Subdomain Mode: Where Platform Differences Emerge
Subdomain multisite requires wildcard DNS and, ideally, wildcard SSL. This is where each platform diverges significantly.
WP Engine does not support wildcard SSL certificates on Growth or Scale plans. Each subdomain must be added individually through the WP Engine portal, and each one triggers a separate Let’s Encrypt certificate issuance. For a network with 20 subsites, that means 20 individual domains in the portal and 20 separate SSL certificates. WP Engine’s system handles this automatically once the domains are added, but the initial setup is tedious and the portal has a rate limit on domain additions.
DNS configuration for WP Engine subdomain multisite requires a wildcard CNAME record pointing to your WP Engine CNAME target:
*.example.com. CNAME example.com.wpengine.com.Pantheon handles subdomain multisite through their Global CDN. Each subdomain must be added as a custom domain in the Pantheon dashboard, and Pantheon provisions automated HTTPS for each one. Wildcard certificates are available on their Enterprise plans but not on Gold or Platinum. The DNS requirement is an A record for each subdomain pointing to Pantheon’s load balancer IP, or a CNAME to their platform domain:
site1.example.com. CNAME fe1.edge.pantheon.io.
site2.example.com. CNAME fe1.edge.pantheon.io.Kinsta supports wildcard SSL through their Cloudflare integration. When you add your root domain to Kinsta, you can request a wildcard certificate that covers all subdomains automatically. This is the simplest subdomain multisite SSL setup among all managed hosts. DNS configuration uses Kinsta’s Cloudflare-powered DNS, and you can set a single wildcard CNAME:
*.example.com. CNAME example.com.kinsta.cloud.Flywheel provisions SSL certificates per domain through Let’s Encrypt. Like WP Engine, there is no wildcard SSL on standard plans. Each subdomain must be registered in the Flywheel dashboard individually. DNS records point to Flywheel’s load balancer:
*.example.com. A Cloudways gives you server access, so you can install a wildcard Let’s Encrypt certificate yourself using Certbot:
certbot certonly --manual --preferred-challenges=dns \
-d "example.com" -d "*.example.com"You then configure the certificate in your Nginx or Apache virtual host configuration. Cloudways also supports wildcard SSL through their platform’s SSL management panel if you prefer a GUI approach.
WP Engine Multisite: Deprecated Workarounds and Memory Limits
WP Engine is one of the most popular managed WordPress hosts, and their multisite support has improved significantly over the years. But several legacy issues and platform-specific constraints still catch teams off guard.
The .htaccess Problem
WP Engine runs Nginx, not Apache. This means .htaccess files are not processed by the web server in the traditional sense. WP Engine maintains a compatibility layer that translates common .htaccess directives into Nginx rules, but this translation is incomplete and occasionally unreliable for multisite configurations.
The standard WordPress multisite .htaccess rules for subdirectory mode look like this:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]On WP Engine, these rules are largely ignored because the platform’s Nginx configuration handles multisite routing internally. The problem arises when plugins or custom code attempt to modify .htaccess for multisite-specific redirects. Those modifications will not take effect.
If you need custom redirect rules on WP Engine multisite, you have two options:
1. Use WP Engine’s “Redirect Rules” feature in the portal, which supports basic redirects but not complex conditional logic.
2. Implement redirects in PHP using the template_redirect or init hooks:
add_action( 'template_redirect', function() {
if ( is_main_site() && isset( $_SERVER['REQUEST_URI'] ) ) {
$path = trim( $_SERVER['REQUEST_URI'], '/' );
if ( $path === 'old-page' ) {
wp_redirect( network_site_url( '/new-page/' ), 301 );
exit;
}
}
});This PHP-based approach works reliably on WP Engine but adds overhead compared to server-level redirects. For sites with hundreds of redirect rules, consider a dedicated redirect plugin that stores rules in the database rather than .htaccess.
Memory Limits: The 64MB Default
WP Engine sets PHP memory limits at the environment level, and the default for many environments is 64MB. For a single site, 64MB is often adequate. For a multisite network, it is almost always insufficient.
When WordPress loads a multisite request, it performs additional database queries to identify the current site, load network-level options, and merge site-specific options with network defaults. Each subsite adds overhead. A multisite network with 15 subsites running WooCommerce or a page builder will routinely exceed 64MB during admin operations.
You cannot set WP_MEMORY_LIMIT in wp-config.php on WP Engine and expect it to work. The platform overrides this constant. To increase memory limits, you must contact WP Engine support or adjust the setting through the WP Engine User Portal under the environment’s PHP settings:
# This will NOT work on WP Engine - the platform overrides it
define( 'WP_MEMORY_LIMIT', '256M' );
# Instead, use WP Engine's portal:
# Sites > Your Environment > PHP Settings > Memory LimitWP Engine’s support team can increase the memory limit to 128MB, 256MB, or 512MB depending on your plan. On Growth plans, the maximum is typically 256MB. Scale and custom plans can go higher.
File Upload Paths
WP Engine handles the /wp-content/uploads/sites/ directory structure correctly for multisite, but their CDN (powered by Cloudflare or their legacy MaxCDN integration) requires configuration to serve subsite media files from the correct paths.
If you are using WP Engine’s CDN, verify that the CDN pull zone includes the /wp-content/uploads/sites/* path. Missing this configuration results in 404 errors for media files on subsites while the main site’s media works fine.
Staging and Development Environments
WP Engine allows you to copy production multisite environments to staging. When you do this, the domain mappings in the wp_blogs and wp_site tables are updated automatically for the main site but not always for subsites with custom domains. After copying to staging, run a search-replace:
# SSH into WP Engine environment
wp search-replace 'example.com' 'example.wpengine.com' --network --url=example.comNote that WP Engine’s own “Copy Environment” feature handles the main site domain replacement but can miss custom-mapped domains on subsites. Always verify subsite URLs after copying environments.
Pantheon Multisite: Composer Workflows and WP-CLI Challenges
Pantheon’s approach to WordPress hosting is fundamentally different from traditional managed hosts. Their infrastructure uses a containerized, Git-based deployment workflow that treats the codebase as immutable in production. This design philosophy creates both advantages and complications for multisite.
Composer-Managed Multisite Setup
Pantheon recommends (and increasingly requires) Composer-based WordPress installations. For multisite, this means your composer.json manages WordPress core, plugins, and themes as dependencies. The multisite configuration lives in your wp-config.php, which is part of your Git repository.
A typical Pantheon multisite composer.json includes:
{
"name": "pantheon-systems/wordpress-multisite",
"type": "project",
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org"
}
],
"require": {
"pantheon-systems/wordpress-composer": "^6.4",
"wpackagist-plugin/wordpress-mu-domain-mapping": "^1.0",
"wpackagist-plugin/wp-native-php-sessions": "^1.4"
},
"extra": {
"wordpress-install-dir": "web/wp",
"installer-paths": {
"web/wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
"web/wp-content/themes/{$name}/": ["type:wordpress-theme"],
"web/wp-content/mu-plugins/{$name}/": ["type:wordpress-muplugin"]
}
}
}The wp-native-php-sessions plugin is required on Pantheon because their infrastructure does not support native PHP sessions. Without it, admin sessions break unpredictably across subsites.
The WP-CLI HTTP_HOST Problem
This is arguably the most frustrating Pantheon-specific multisite issue. When you run WP-CLI commands on Pantheon via Terminus (their CLI tool), the HTTP_HOST server variable is not set. WordPress multisite relies on HTTP_HOST to determine which site in the network is being accessed. Without it, WP-CLI commands default to the main site or fail entirely.
The symptom looks like this:
$ terminus wp mysite.live -- option get siteurl --url=subsite.example.com
Error: Site 'subsite.example.com' not found.The workaround requires explicitly passing the URL and sometimes also setting the HTTP_HOST environment variable:
# Method 1: Use the --url flag with the full URL including protocol
terminus wp mysite.live -- option get siteurl --url=https://subsite.example.com
# Method 2: For complex operations, set HTTP_HOST in a wp-cli.yml file
# Place this in the root of your Pantheon repository:
# wp-cli.yml
@production:
url: https://example.com
ssh: [email protected]
# Method 3: Use a wrapper script in your repository
# bin/wp-multisite.sh
#!/bin/bash
SITE_URL="${1}"
shift
terminus wp mysite.live -- "$@" --url="${SITE_URL}"For batch operations across all subsites, you need to script the site iteration yourself:
#!/bin/bash
# Get all site URLs in the network
SITES=$(terminus wp mysite.live -- site list --field=url --url=https://example.com)
for SITE in $SITES; do
echo "Processing: $SITE"
terminus wp mysite.live -- plugin update --all --url="$SITE"
donePantheon’s Dev/Test/Live Workflow with Multisite
Pantheon’s three-environment workflow (Dev, Test, Live) introduces complexity for multisite because the database contains hardcoded domain references. When you deploy code from Dev to Test to Live, the code moves but the database does not automatically follow. When you clone the Live database down to Dev for testing, all the domain references point to production URLs.
Pantheon provides a wp search-replace operation through Terminus, but for multisite networks you need to run it for each subsite:
# After cloning Live database to Dev environment
terminus wp mysite.dev -- search-replace 'example.com' 'dev-mysite.pantheonsite.io' \
--network --url=https://example.com
# Verify each subsite
terminus wp mysite.dev -- site list --url=https://dev-mysite.pantheonsite.ioFile System Restrictions
Pantheon’s file system is split into two components: the code directory (Git-managed, read-only in Test and Live) and the files directory (writable, stored on a shared file system). For multisite, the wp-content/uploads/sites/ directory lives in the files directory and is writable across all environments.
One gotcha: Pantheon’s file system does not support symlinks in the files directory. Some multisite plugins that create symlinks for shared media libraries will fail silently. If you need shared media across subsites on Pantheon, use a plugin that copies files or references them via URL rather than filesystem symlinks.
Kinsta Multisite: MyKinsta Dashboard and Environment Management
Kinsta’s multisite support is integrated into their MyKinsta dashboard, and their Google Cloud Platform infrastructure provides solid performance for multisite networks. But several operational details require attention.
Setting Up Multisite Through MyKinsta
Kinsta does not allow you to enable multisite yourself through wp-config.php changes on an existing installation. You must either request multisite activation through Kinsta support or select the multisite option when creating a new WordPress installation through MyKinsta.
When creating a new site in MyKinsta:
1. Select “Install WordPress Multisite” during the site creation wizard.
2. Choose between subdomain and subdirectory. This choice is permanent on Kinsta without a full reinstallation.
3. Kinsta configures the Nginx server blocks, wp-config.php constants, and file upload paths automatically.
If you have an existing single-site installation on Kinsta that you want to convert to multisite, contact support. They will modify the Nginx configuration and update wp-config.php for you. Do not attempt to edit wp-config.php directly through SFTP to enable multisite, as the Nginx configuration also needs updating and you do not have access to modify Nginx on Kinsta.
Adding Subsites and Domains
For subdirectory multisite, adding new subsites through the WordPress Network Admin works without any Kinsta-specific configuration. The subsite is immediately accessible at the subdirectory path.
For subdomain multisite, each new subsite requires two steps:
1. Create the subsite in WordPress Network Admin.
2. Add the subdomain as a domain in MyKinsta under “Domains.”
If you skip step 2, the subdomain will resolve to a DNS error or the wrong site. Kinsta’s Cloudflare integration means you can manage DNS directly in MyKinsta if you use Kinsta DNS:
# In MyKinsta > Sites > Your Site > Domains
# Add: newsubsite.example.com
# Point DNS: CNAME to your-site.kinsta.cloud
# SSL is provisioned automatically via CloudflarePush Environments and Multisite
Kinsta allows you to push from staging to production. For multisite networks, this push operation has specific behavior you need to understand.
When you push staging to production, Kinsta offers three options: push files only, push database only, or push both. For multisite, pushing the database is where problems occur.
The database push performs a search-replace for the staging domain to the production domain, but it only targets the main site’s domain. Subsites with custom domain mappings will have their domains replaced incorrectly, or not replaced at all. After a database push, you must manually verify and fix subsite URLs:
# SSH into Kinsta environment
wp site list --url=example.com
# If subsites show staging URLs, fix them individually
wp search-replace 'staging-example.kinsta.cloud' 'example.com' \
--url=staging-example.kinsta.cloud --all-tables-with-prefix
# For subsites with custom domains
wp search-replace 'stg-clientsite.kinsta.cloud' 'clientsite.com' \
--url=stg-clientsite.kinsta.cloud --all-tables-with-prefixA safer workflow is to push files only from staging to production, and manage database changes through WP-CLI or migration plugins. This avoids the domain replacement issues entirely.
PHP Workers and Multisite Performance
Each Kinsta plan allocates a specific number of PHP workers. These workers are shared across the entire multisite network. A Business plan includes 4 PHP workers. When one subsite receives heavy traffic or runs a slow database query, it consumes workers that other subsites need.
Monitor PHP worker usage in MyKinsta’s analytics dashboard. If you regularly see “PHP worker limit reached” errors, you either need to optimize slow queries across your subsites or upgrade to a plan with more workers. There is no way to allocate workers to specific subsites within a network.
Flywheel Multisite: Aggregate Limits and Missing Features
Flywheel has a clean, design-friendly interface that appeals to agencies, but their multisite implementation has several notable limitations.
Aggregate Resource Limits
Flywheel’s resource limits (bandwidth, storage, visits) apply to the entire multisite network as a single unit. There is no per-subsite resource tracking or allocation. This creates a management challenge for agencies that use multisite to host multiple client sites: you cannot determine which client’s site is consuming the most resources without external analytics.
If one client’s site gets a traffic spike, it can push the entire network over its resource limits, affecting all other subsites. Flywheel charges overage fees for bandwidth and visit overages, and these overages apply to the network as a whole.
No Blueprint Support for Multisite
Flywheel’s Blueprint feature lets you create templated WordPress installations that can be deployed as new sites. Blueprints do not support multisite networks. You cannot create a blueprint from a multisite installation, and you cannot deploy a blueprint as a multisite network.
This means every new multisite deployment on Flywheel starts from scratch. For agencies that frequently deploy similar multisite configurations, this lack of templating adds significant setup time. The workaround is to maintain a “golden” multisite installation that you manually duplicate through Flywheel’s site cloning feature, but cloning is slower and less reliable than blueprints.
Local Development Integration
Flywheel’s Local development application (Local by Flywheel, now just “Local”) supports multisite for local development. You can create a multisite installation in Local and push it to Flywheel. However, the push process has the same domain replacement limitations described for Kinsta. Custom domain mappings on subsites require manual correction after pushing.
To set up multisite in Local for Flywheel deployment:
# In Local, create a new site, then:
# 1. Open the site shell
wp core multisite-install --title="My Network" \
--admin_user=admin --admin_password=password \
[email protected] --subdomains
# 2. Create subsites
wp site create --slug=client1 --title="Client 1"
wp site create --slug=client2 --title="Client 2"
# 3. Push to Flywheel via Local's "Push to Flywheel" feature
# 4. After push, SSH in and fix domains
wp search-replace 'mysite.local' 'mysite.getflywheel.com' --networkSSL on Flywheel Multisite
Flywheel provisions free SSL certificates through Let’s Encrypt for all domains. For subdomain multisite, each subdomain needs to be added to the Flywheel dashboard individually. The SSL provisioning takes a few minutes per domain and happens automatically once the DNS is properly configured.
For large multisite networks with many subdomains, adding each one manually through the dashboard is tedious. Flywheel does not offer API access for domain management, so there is no way to script this process. If you are deploying a multisite network with more than 20 subdomains, contact Flywheel support for bulk domain addition.
Cloudways Multisite: Full Control with Full Responsibility
Cloudways gives you more configuration access than any other platform on this list, which makes it both the most flexible and the most demanding option for multisite.
.htaccess and Nginx Configuration
Cloudways supports both Apache and Nginx. If you select Apache as your web server, .htaccess rules work as expected and the standard WordPress multisite rewrite rules function without modification.
If you select Nginx (recommended for performance), you need to configure the multisite rewrite rules in the Nginx configuration. Cloudways provides an interface for custom Nginx directives through their platform dashboard:
# For subdirectory multisite on Cloudways Nginx
# Add to Nginx configuration via Cloudways dashboard
# Server Management > Settings & Packages > Nginx Configuration
if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
rewrite ^(/[^/]+)?(/wp-.*) $2 last;
rewrite ^(/[^/]+)?(/.*\.php) $2 last;
}
# For subdomain multisite on Cloudways Nginx
# The server block needs to handle wildcard subdomains
server_name example.com *.example.com;For subdomain installations on Nginx, you also need to ensure the server block’s server_name directive includes the wildcard. On Cloudways, this is configured through the Application Settings:
# Cloudways Dashboard > Application > Domain Management
# Add: example.com
# Add: *.example.com (if supported, otherwise add each subdomain)Redis Object Cache with Multisite on Cloudways
Cloudways offers one-click Redis installation, but configuring Redis for multisite requires additional steps. The default Redis configuration uses a single database (database 0) for all cache keys. In a multisite installation, this means all subsites share the same Redis keyspace, which can cause key collisions if two subsites use plugins that generate identical cache keys.
The solution is to configure unique key prefixes per subsite. The recommended approach uses the WP_CACHE_KEY_SALT constant, but for multisite this needs to be dynamic:
// In wp-config.php - Dynamic cache key salt for multisite
if ( defined( 'MULTISITE' ) && MULTISITE ) {
// Each subsite gets a unique cache prefix based on blog ID
// This is handled automatically by most object cache plugins
// but verify your plugin supports multisite key isolation
define( 'WP_CACHE_KEY_SALT', 'mynetwork_' );
}
// Redis configuration for Cloudways
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );Most modern Redis object cache plugins (Redis Object Cache by Till Kruss, Object Cache Pro) handle multisite key isolation automatically by prepending the blog ID to each cache key. Verify this behavior after installation by inspecting the Redis keyspace:
# SSH into Cloudways server
redis-cli
> KEYS *
# You should see keys prefixed with blog IDs like:
# "mynetwork_1:options:alloptions"
# "mynetwork_2:options:alloptions"
# "mynetwork_3:posts:123"If you see keys without blog ID prefixes, your object cache plugin is not properly isolating multisite cache keys, and you need to switch to one that does.
Server-Level Caching and Multisite
Cloudways includes Varnish or Nginx FastCGI caching at the server level. For multisite, the caching layer needs to differentiate between subsites. Subdirectory multisite generally works because the URL path differs between subsites. Subdomain multisite requires the cache to vary by hostname.
On Cloudways with Nginx FastCGI caching, verify that the cache key includes the hostname:
# The default Cloudways Nginx FastCGI cache key should include $host
fastcgi_cache_key "$scheme$request_method$host$request_uri";If the cache key does not include $host, all subdomains will serve the same cached content, which is a serious bug that will be immediately obvious in testing but devastating if it reaches production.
Domain Mapping Strategies Per Platform
Domain mapping allows subsites to use their own custom domains instead of subdomains or subdirectory paths. A subsite at example.com/clientsite or clientsite.example.com can instead respond at clientsite.com. This is essential for agencies using multisite to host client websites.
Since WordPress 4.5, basic domain mapping is built into WordPress core through the “Site Address (URL)” field in each subsite’s settings. Third-party domain mapping plugins like WordPress MU Domain Mapping are no longer required for basic functionality. However, the platform-specific requirements for making domain mapping work vary significantly.
WP Engine Domain Mapping
On WP Engine, each mapped domain must be added to the environment through the WP Engine portal. WP Engine will provision an SSL certificate for each domain. After adding the domain in the portal:
1. Update DNS for the mapped domain to point to your WP Engine CNAME target.
2. In WordPress Network Admin, edit the subsite and change the “Site Address” to the mapped domain.
3. Clear WP Engine’s cache through the portal or using the WP Engine PHP helper:
// Programmatic cache clear on WP Engine after domain mapping
if ( class_exists( 'WpeCommon' ) ) {
WpeCommon::purge_memcached();
WpeCommon::purge_varnish_cache();
}Kinsta Domain Mapping
On Kinsta, add the mapped domain under your site’s “Domains” section in MyKinsta. Kinsta will automatically provision SSL via their Cloudflare integration. Then update the subsite’s URL in WordPress:
# Via WP-CLI on Kinsta
wp site list --url=example.com
wp option update siteurl 'https://clientsite.com' --url=example.com/clientsite
wp option update home 'https://clientsite.com' --url=example.com/clientsite
# Run search-replace for content URLs
wp search-replace 'example.com/clientsite' 'clientsite.com' \
--url=example.com/clientsite --all-tables-with-prefixPantheon Domain Mapping
On Pantheon, add each mapped domain through the Pantheon dashboard or Terminus:
# Add domain via Terminus
terminus domain:add mysite.live -- clientsite.com
# Verify domain
terminus domain:list mysite.liveThen update the subsite URL in WordPress and configure DNS to point to Pantheon’s edge servers.
Cloudways Domain Mapping
On Cloudways, add the mapped domain through the Application’s Domain Management. Then configure the server’s virtual host to recognize the new domain. For Nginx:
# The server block should list all mapped domains
server_name example.com *.example.com clientsite.com anotherclient.com;Alternatively, you can set up separate server blocks for each mapped domain that proxy to the same application. This gives you more granular control over per-domain SSL certificates and caching rules.
Backup and Restore of Individual Subsites
One of the most significant operational challenges with WordPress Multisite on any platform is backup and restore granularity. Multisite networks share a single database with per-site table prefixes, a single wp-content directory (with per-site upload directories), and a single codebase. Platform backup systems are designed for whole-site backups, not subsite-level backups.
The Shared Database Problem
In a multisite network, each subsite has its own set of tables with a prefix based on the blog ID. The main site uses the standard wp_ prefix, and subsites use wp_2_, wp_3_, etc. But several tables are shared across the entire network:
wp_users
wp_usermeta
wp_blogs
wp_blogmeta
wp_site
wp_sitemeta
wp_registration_log
wp_signupsThese shared tables mean you cannot simply export a subsite’s tables, import them into a separate installation, and expect everything to work. User references, network settings, and site registration data are intertwined.
Platform Backup Capabilities
WP Engine creates daily automated backups and supports on-demand backups. All backups capture the entire multisite network. There is no option to back up or restore a single subsite. Restoring a backup restores the entire network to that point in time, which means reverting one subsite’s changes also reverts every other subsite’s changes.
Kinsta provides daily automated backups with a 14-day retention period (30 days on higher plans). Like WP Engine, backups cover the entire installation. Kinsta offers a “Search and Replace” tool in MyKinsta, but no subsite-level backup or restore.
Pantheon creates backups at the environment level. Each backup captures the full database, files, and code. The Git-based workflow means code can be reverted independently, but database and files are all-or-nothing.
Flywheel creates nightly backups of the entire installation. No subsite-level granularity.
Cloudways creates automated backups of the entire server or application. Like the others, no subsite-level backup built in.
Workaround: WP-CLI Subsite Export
The practical workaround for subsite-level backup is using WP-CLI to export individual subsites:
# Export a single subsite's content
wp export --url=subsite.example.com --dir=/tmp/backups/
# Export specific subsite tables
wp db export /tmp/backups/subsite2_tables.sql \
--tables=$(wp db tables 'wp_2_*' --url=subsite.example.com --format=csv)
# Export subsite uploads
tar -czf /tmp/backups/subsite2_uploads.tar.gz \
wp-content/uploads/sites/2/To restore a subsite from these exports:
# Import subsite tables (after dropping existing ones)
wp db import /tmp/backups/subsite2_tables.sql --url=subsite.example.com
# Import content via WordPress importer
wp import /tmp/backups/subsite.example.com.wordpress.xml \
--url=subsite.example.com --authors=mapping.csv
# Restore uploads
tar -xzf /tmp/backups/subsite2_uploads.tar.gz -C /For production multisite networks, consider a plugin like UpdraftPlus (which supports per-subsite backup on some multisite configurations) or a custom WP-CLI script that runs nightly exports of each subsite.
Object Cache Considerations for Multisite Across Platforms
Object caching is critical for multisite performance because the additional database queries required for multisite operations (site identification, network option loading, user role resolution across sites) benefit enormously from being cached in memory.
Redis vs. Memcached for Multisite
Both Redis and Memcached work with WordPress multisite, but Redis is the better choice for two reasons. First, Redis supports data persistence, so cached data survives a server restart. Second, Redis supports key namespacing through database selection, which provides an additional isolation layer beyond key prefixes.
On platforms that offer both:
– WP Engine uses their own proprietary object caching (formerly based on Memcached, now their own system). You cannot choose Redis on standard plans.
– Kinsta uses Redis. It is included on all plans that support multisite and is configured automatically.
– Pantheon provides Redis through their platform. Enable it in the Pantheon dashboard and install the wp-redis plugin.
– Flywheel does not offer Redis or Memcached on standard plans. Object caching is limited to the default file-based transient cache.
– Cloudways offers both Redis and Memcached. Redis is recommended.
Cache Key Isolation
The most important object cache consideration for multisite is key isolation. Without proper isolation, cached data from one subsite can leak into another. This is not a theoretical risk. I have personally debugged production multisite networks where user session data from one subsite was being served to users on a different subsite because of cache key collisions.
The WordPress object cache API includes a $blog_id parameter in its internal key generation. Well-written object cache drop-ins use this parameter to prefix all keys with the blog ID. But not all drop-ins handle this correctly, and some older drop-ins ignore it entirely.
Verify your object cache isolation with this test:
# On the main site (blog ID 1)
wp eval "wp_cache_set('test_key', 'main_site_value', 'test_group'); echo wp_cache_get('test_key', 'test_group');" --url=example.com
# On a subsite (blog ID 2)
wp eval "echo wp_cache_get('test_key', 'test_group');" --url=subsite.example.com
# If the subsite returns 'main_site_value', your cache is NOT properly isolatedIf you find that cache keys are not isolated, switch to a drop-in that properly supports multisite. Object Cache Pro is the gold standard for this, as it handles multisite isolation, per-site cache flushing, and analytics across the network.
Cache Flushing Per Subsite
When you flush the object cache on a multisite network, you need to decide whether to flush the entire network’s cache or just a single subsite’s cache. Most platform-level cache flush tools (WP Engine’s “Clear All Caches,” Kinsta’s “Clear Cache” button) flush the entire network.
For per-subsite cache flushing via WP-CLI:
# Flush cache for a specific subsite
wp cache flush --url=subsite.example.com
# Flush cache for the entire network
wp cache flush --networkBe aware that wp cache flush with a specific URL only works if your object cache drop-in supports per-site flushing. Some drop-ins flush everything regardless of the --url parameter.
Performance Implications of Multisite on Shared Hosting Resources
Multisite networks share server resources across all subsites. Understanding how this sharing works on managed platforms is essential for capacity planning.
PHP Workers and Concurrency
Every managed host allocates a fixed number of PHP workers (or PHP-FPM processes) per installation. In a multisite network, all subsites compete for the same pool of workers. When a PHP worker is handling a request for one subsite, it is unavailable for requests to other subsites.
The practical impact: a subsite running a slow WooCommerce checkout process can block PHP workers that would otherwise serve requests to other subsites. If all workers are occupied, incoming requests queue and eventually time out.
Worker allocation by platform:
– WP Engine Growth: Varies by environment, typically 4-8 workers
– Kinsta Business: 4 PHP workers
– Pantheon Gold: Scales dynamically based on traffic (container-based)
– Flywheel Freelance: Not publicly documented; contact support for specifics
– Cloudways: Depends on server size; fully configurable via PHP-FPM settings
For multisite networks with more than 5 active subsites, calculate your PHP worker needs by summing the expected concurrent requests across all subsites, not just the busiest one.
Database Connection Pooling
WordPress uses a single database connection per request. In a multisite network, the database handles queries for all subsites through the same connection pool. Managed hosts typically set a maximum connection limit at the database level.
On WP Engine and Kinsta, database connection limits are managed automatically and scale with your plan. On Cloudways, you can configure MySQL’s max_connections parameter:
# Cloudways: Adjust MySQL max connections
# Server Management > Settings & Packages > MySQL
# Increase max_connections from default (usually 100-150)
# For multisite with 20+ active subsites, consider 300+On Pantheon, the database layer uses a connection pooler that handles connection management automatically. However, long-running queries can still exhaust the pooler’s capacity.
Disk I/O and Storage
Multisite networks accumulate disk usage faster than single sites because each subsite generates its own upload directory, its own set of cached files (if using file-based caching), and its own set of transient data.
Monitor disk usage per subsite with:
# Check uploads directory size per subsite
du -sh wp-content/uploads/sites/*/
# Check total database size per subsite
wp db size --tables --human-readable --url=example.com | grep "wp_2_"
wp db size --tables --human-readable --url=example.com | grep "wp_3_"On platforms with storage limits (WP Engine: 10GB on Growth, Kinsta: 30GB on Business, Flywheel: varies by plan), a single subsite with large media files can consume the network’s entire storage allocation.
CDN and Edge Caching
Every managed platform includes CDN capabilities, either built-in (WP Engine, Kinsta, Flywheel) or configurable (Cloudways, Pantheon). For multisite, the CDN must correctly handle multiple origins or URL paths.
Subdirectory multisite works seamlessly with CDNs because all content is served from the same domain. The CDN caches content based on the URL path, and each subsite’s content has a unique path prefix.
Subdomain multisite requires the CDN to serve content for multiple hostnames. Most platform CDNs handle this automatically, but if you are using a third-party CDN (Cloudflare, Fastly, StackPath), verify that all subsite domains are included in the CDN configuration:
# Cloudflare: Each subdomain must be proxied (orange cloud)
# In Cloudflare DNS for example.com:
# *.example.com CNAME example.com (Proxied)
# Or individually:
# site1.example.com CNAME example.com (Proxied)
# site2.example.com CNAME example.com (Proxied)Migration: Moving Sites In and Out of Multisite Networks
Migration is the most technically demanding multisite operation. Moving a standalone WordPress site into a multisite network, or extracting a subsite out of a network into its own installation, requires careful handling of database tables, upload paths, user records, and URL references.
Moving a Standalone Site Into a Multisite Network
The general process:
1. Create a new subsite in the multisite network.
2. Export content from the standalone site.
3. Import content into the new subsite.
4. Migrate media files to the correct uploads subdirectory.
5. Run search-replace for URL references.
6. Verify theme and plugin compatibility.
Using WP-CLI:
# Step 1: Create the subsite
wp site create --slug=newsite --title="New Site" --url=example.com
# Step 2: Export from standalone (on the standalone server)
wp export --dir=/tmp/migration/
# Step 3: Import into subsite
wp import /tmp/migration/standalone.wordpress.xml \
--url=example.com/newsite --authors=create
# Step 4: Copy uploads
# From standalone: wp-content/uploads/
# To multisite: wp-content/uploads/sites/{blog_id}/
rsync -avz standalone-server:/var/www/html/wp-content/uploads/ \
./wp-content/uploads/sites/4/
# Step 5: Search-replace
wp search-replace 'standalone-domain.com' 'example.com/newsite' \
--url=example.com/newsite --all-tables-with-prefix
# Also fix upload paths
wp search-replace '/wp-content/uploads/' '/wp-content/uploads/sites/4/' \
--url=example.com/newsite --all-tables-with-prefixThe tricky part is the upload path replacement. Standalone WordPress stores uploads in wp-content/uploads/YYYY/MM/. Multisite stores subsite uploads in wp-content/uploads/sites/{blog_id}/YYYY/MM/. Every reference to an upload in post content, post meta, widget content, and theme options needs to be updated.
Extracting a Subsite Out of a Multisite Network
Moving a subsite out to a standalone installation is more complex because you need to untangle the shared components:
# Step 1: Export content from the subsite
wp export --url=subsite.example.com --dir=/tmp/extraction/
# Step 2: Export subsite database tables
BLOG_ID=3
TABLES=$(wp db tables "wp_${BLOG_ID}_*" --url=subsite.example.com --format=csv)
wp db export /tmp/extraction/subsite_tables.sql --tables="$TABLES"
# Step 3: Export relevant users
wp user list --url=subsite.example.com --format=json > /tmp/extraction/users.json
# Step 4: Copy subsite uploads
cp -R wp-content/uploads/sites/${BLOG_ID}/ /tmp/extraction/uploads/
# On the standalone installation:
# Step 5: Import the exported content
wp import /tmp/extraction/subsite.example.com.wordpress.xml --authors=create
# Step 6: Copy uploads
cp -R /tmp/extraction/uploads/* wp-content/uploads/
# Step 7: Search-replace
wp search-replace 'subsite.example.com' 'newstandalone.com' --all-tables
wp search-replace '/wp-content/uploads/sites/3/' '/wp-content/uploads/' --all-tablesPlatform-Specific Migration Tools
WP Engine has an automated migration plugin that supports multisite. Install the “WP Engine Automated Migration” plugin on your source installation, and it will copy the entire multisite network to WP Engine. However, if you only want to migrate specific subsites, you need the manual WP-CLI approach described above.
Kinsta offers free migration for new customers, and their migration team handles multisite networks. They request SSH or SFTP access to the source server and handle the migration themselves. For subsequent migrations, you can use WP-CLI through Kinsta’s SSH access.
Pantheon provides the Terminus Migrate plugin for WordPress migrations. For multisite, you need Terminus and WP-CLI:
# On Pantheon, after initial multisite setup
terminus wp mysite.dev -- db import /path/to/exported-database.sql \
--url=https://dev-mysite.pantheonsite.io
# Then run search-replace for the new domain
terminus wp mysite.dev -- search-replace 'old-domain.com' \
'dev-mysite.pantheonsite.io' --networkCloudways supports migration through their platform migration tool or through manual methods. Because you have full server access, you can use any migration approach: database export/import, file rsync, or all-in-one migration plugins like All-in-One WP Migration (which supports multisite on its premium extension).
Post-Migration Verification Checklist
After any multisite migration, regardless of platform, verify these items:
# 1. Check all site URLs in the network
wp site list --fields=blog_id,url,domain,path
# 2. Verify siteurl and home for each subsite
for SITE in $(wp site list --field=url); do
echo "--- $SITE ---"
wp option get siteurl --url="$SITE"
wp option get home --url="$SITE"
done
# 3. Check for broken media URLs
wp db query "SELECT ID, guid FROM wp_2_posts WHERE post_type='attachment' LIMIT 5" \
--url=subsite.example.com
# 4. Verify user roles across subsites
wp user list --url=subsite.example.com --fields=ID,user_login,roles
# 5. Test permalink structure
wp rewrite flush --url=subsite.example.com
# 6. Verify upload paths
wp eval "echo wp_upload_dir()['basedir'];" --url=subsite.example.com
# Should output: /path/to/wp-content/uploads/sites/{blog_id}Production Stability Practices for Multisite on Managed Hosts
Running a multisite network in production requires discipline beyond what a single-site WordPress installation demands. The shared nature of the platform means that a mistake on one subsite can cascade across the network.
Plugin Activation Scope
In a multisite network, plugins can be activated at two levels: network-wide (activated for all subsites simultaneously) or per-site (activated only on specific subsites). On managed hosting platforms, this distinction has performance and stability implications.
Network-activated plugins load on every request to every subsite. A poorly coded network-activated plugin adds overhead to every single page load across the entire network. Per-site activation limits the blast radius of a problematic plugin to a single subsite.
The rule of thumb: only network-activate plugins that every subsite genuinely requires (security plugins, performance plugins, custom functionality that applies network-wide). Activate everything else on a per-site basis.
# Network-activate a plugin
wp plugin activate akismet --network --url=example.com
# Activate a plugin on a specific subsite only
wp plugin activate woocommerce --url=shop.example.com
# List network-activated plugins
wp plugin list --status=active-network --url=example.com
# List per-site activated plugins
wp plugin list --status=active --url=shop.example.comTheme Management
Themes must be “network-enabled” before they can be activated on individual subsites. Only network administrators can enable themes. On managed hosts, this means your deployment workflow must include a step to network-enable any new themes:
# Network-enable a theme
wp theme enable flavor-developer --network --url=example.com
# Activate a theme on a specific subsite
wp theme activate flavor-developer --url=subsite.example.comUpdate Strategy
On managed platforms, WordPress core updates are often handled by the host. For multisite, this means the host updates the single WordPress core installation, and all subsites automatically run the new version. There is no option to run different WordPress versions on different subsites.
Plugin and theme updates, however, are your responsibility. On a multisite network, updating a plugin updates it for every subsite where it is active. Test updates on a staging environment before applying them to production:
# On staging: update all plugins
wp plugin update --all --url=example.com
# Verify each subsite still works
for SITE in $(wp site list --field=url); do
echo "Testing: $SITE"
curl -sL -o /dev/null -w "%{http_code}" "$SITE"
doneMonitoring and Alerting
Set up monitoring for each subsite independently, not just the main site. A network-level health check might show the main site responding normally while a subsite is throwing 500 errors due to a plugin conflict or database issue.
Use an external monitoring service (Uptime Robot, Pingdom, StatusCake) with separate checks for:
– Each subsite’s homepage
– Each subsite’s wp-login.php (verifies PHP processing)
– Each subsite’s wp-cron.php (verifies scheduled tasks)
– The network admin dashboard (verifies administrative access)
Database Maintenance
Multisite databases grow faster than single-site databases because each subsite adds its own set of tables. Transient data, revision accumulation, and spam comment buildup multiply across subsites.
Schedule regular database optimization:
# Delete expired transients across all subsites
for SITE in $(wp site list --field=url); do
wp transient delete --expired --url="$SITE"
done
# Delete post revisions older than 30 days across all subsites
for SITE in $(wp site list --field=url); do
wp post delete $(wp post list --post_type=revision \
--before="30 days ago" --format=ids --url="$SITE") \
--force --url="$SITE" 2>/dev/null
done
# Optimize all database tables
wp db optimizeOn managed platforms, you may not have direct cron access. Use WordPress cron (wp_schedule_event) or the platform’s scheduled task feature (Kinsta’s MyKinsta allows custom cron setup, WP Engine supports custom cron through their support team) to automate these maintenance tasks.
Platform Comparison Summary
After deploying multisite networks across all five platforms discussed in this article, the choice of platform depends on your team’s priorities and technical capabilities.
WP Engine is the safest choice for teams that want managed multisite with minimal server administration. Their multisite support is mature, their support team understands multisite-specific issues, and their caching layer handles multisite correctly out of the box. The limitations around .htaccess, memory defaults, and the lack of subsite-level backups are manageable. Best for: agencies that want reliability and are willing to work within WP Engine’s constraints.
Pantheon is the best choice for teams that follow a Git-based development workflow and want the most control over their deployment process. The Composer-managed setup and the Dev/Test/Live workflow are excellent for teams with development discipline. The WP-CLI/HTTP_HOST issues and the learning curve for Pantheon’s unique architecture are real costs. Best for: development teams that value workflow rigor and already use version control for everything.
Kinsta offers the best balance of managed convenience and multisite features. The Cloudflare-powered wildcard SSL, the MyKinsta dashboard, and the included Redis object cache make subdomain multisite easier to deploy than on any other platform. The limitation around push environments and multisite is the primary pain point. Best for: teams that want modern infrastructure with minimal platform-specific workarounds.
Flywheel appeals to agencies and designers but has the most significant multisite limitations. The aggregate resource limits, the lack of blueprint support, and the absence of Redis or Memcached on standard plans make Flywheel the least suitable platform for large or high-traffic multisite networks. Best for: small agency multisite networks (under 10 subsites) with moderate traffic.
Cloudways is the right choice for teams with server administration skills who need maximum flexibility. You can configure everything, but you must configure everything. There is no multisite-specific support, no automatic SSL for subdomains, and no platform-level cache isolation. Best for: technically skilled teams that need specific server configurations or want to run multisite on infrastructure that managed hosts do not support (custom regions, specific server specs, non-standard caching layers).
The decision is not permanent. Moving a multisite network between platforms is painful but possible using the migration techniques described in this article. Start with the platform that matches your team’s skills and your network’s current requirements. You can migrate later if those requirements change.
Whatever platform you choose, invest the time to understand its specific constraints before deploying your multisite network to production. The platform-specific issues described in this article are not edge cases. They are the standard experience of running WordPress Multisite on managed hosting, and preparing for them will save you significant debugging time when the network is live and serving real traffic.
James Whitfield
Enterprise WordPress architect. Manages multisite networks for university systems and media companies. Expert in scaling WordPress to hundreds of sites.