WordPress Kubernetes Multisite: Solving Storage and Database Persistence

During our last migration of a high-traffic media network, we hit a wall that almost tanked our Q3 release. We were trying to move a massive WordPress Multisite installation into a containerized environment, but the shared upload directories were causing 500 errors across 40% of our sub-sites whenever a pod restarted. The root cause wasn't the application code; it was our reliance on local file system storage for wp-content/uploads, which evaporated the moment the ephemeral pods were rescheduled.

Architecting WordPress Kubernetes for Scale

Running a WordPress Multisite setup on a cluster is fundamentally different from a standard single-site instance. You aren't just managing one database; you’re managing a shared filesystem where assets are generated dynamically. If you don't nail your Persistent Volume Claims (PVCs) early, you’ll end up with broken images and missing media across your network.

We initially tried using a standard ReadWriteOnce (RWO) volume, thinking we could just pin the pods to specific nodes. That failed immediately when we tried to scale past a single pod. Once the Horizontal Pod Autoscaler kicked in, the new pods couldn't mount the volume, and we were left with a fragmented mess. If you're serious about scaling your architecture, you should first master WordPress Kubernetes performance so you understand how caching layers interact with your storage choices.

Navigating Kubernetes StorageClasses

To get this right, we moved to an ReadWriteMany (RWX) storage solution. We settled on an NFS-backed Kubernetes StorageClasses configuration, which allowed all pods to mount the same upload directory simultaneously. It wasn't perfect, though. We saw latency spikes of around 320ms when multiple pods attempted to write to the same metadata file simultaneously—a known limitation of NFS in high-concurrency scenarios.

If I had to do it again, I’d skip the NFS experiment entirely and go straight to an S3-compatible object store using a plugin like S3-Uploads. It offloads the storage entirely, meaning your pods stay ephemeral and you stop worrying about block storage constraints.

Database Persistence and State

When it comes to WordPress Containerization, the database is your biggest single point of failure. You cannot treat your database like an application pod. For our production environment, we moved away from managing raw MySQL manifests and shifted to CloudNativePG for reliable Kubernetes database management. It turned a fragile, manual failover process into an automated, self-healing system that actually handles the complexity of stateful workloads.

Here is a simplified look at how we structure our stateful sets to ensure persistence:

YAML
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wordpress-multisite
spec:
  volumeClaimTemplates:
  - metadata:
      name: wp-uploads
    spec:
      accessModes: [ "ReadWriteMany" ]
      storageClassName: "nfs-client"
      resources:
        requests:
          storage: 100Gi

We still wrestle with the complexity of cache invalidation across the multisite network. Every time we update a global theme, we have to ensure the wp-content sync is instantaneous, or the sub-sites show inconsistent UI states. It took us roughly four days to get the sync logic right, and honestly, I'm still not 100% confident that our current file-locking mechanism won't fail under extreme load.

FAQ

Q: Can I use local storage for WordPress Multisite? A: Only if you're running a single pod. For any production environment requiring high availability, local storage will break your site whenever a pod moves.

Q: Is ReadWriteMany (RWX) necessary for all WordPress setups? A: Only if you are using a shared filesystem for media. If you offload media to S3, you can use ReadWriteOnce (RWO) volumes for configuration files, which is much faster.

Q: How do you handle database backups in Kubernetes? A: Don't rely on pod-level snapshots. Use an operator-based approach like CloudNativePG to handle streaming backups to an external S3 bucket.

I'm still looking for a cleaner way to handle the shared asset sync without relying on NFS, but for now, it’s the compromise we’ve accepted to keep the site running. If you're planning your own migration, start by simplifying your storage layer before you touch the database. It’s a lot harder to fix a broken storage backend than it is to re-import a database.