Deploy a production-ready WordPress Multisite network on Kubernetes with shared persistent storage, Nginx Ingress, TLS termination, and horizontal pod autoscaling.
Introduction
WordPress Multisite lets you run dozens or hundreds of sites from a single WordPress installation. Combining it with Kubernetes gives you automatic scaling, rolling deployments, and infrastructure-as-code. However, the combination introduces challenges around shared file storage, database connections, and domain routing.
This guide covers deploying WordPress Multisite on Kubernetes using Helm, NFS-backed persistent volumes, and Nginx Ingress with wildcard TLS certificates.
Prerequisites
- A Kubernetes cluster (EKS, GKE, or self-managed) running 1.28 or later
- kubectl and Helm 3 installed locally
- An NFS server or EFS file system for shared uploads
- A wildcard DNS record pointing to your Ingress load balancer
Namespace and Storage Setup
kubectl create namespace wordpress
# Create PersistentVolume backed by NFS
kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: wp-uploads-pv
spec:
capacity:
storage: 50Gi
accessModes:
- ReadWriteMany
nfs:
server: 10.0.1.50
path: /exports/wp-uploads
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wp-uploads-pvc
namespace: wordpress
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 50Gi
EOF
ReadWriteMany access mode is critical because multiple pods need to read and write uploaded media simultaneously.
Deploying with Helm
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install wp-multisite bitnami/wordpress \
--namespace wordpress \
--set wordpressUsername=admin \
--set wordpressPassword=<strong-password> \
--set multisite.enable=true \
--set multisite.networkType=subdomain \
--set multisite.host=example.com \
--set persistence.existingClaim=wp-uploads-pvc \
--set replicaCount=3 \
--set resources.requests.cpu=250m \
--set resources.requests.memory=256Mi \
--set resources.limits.cpu=1 \
--set resources.limits.memory=512Mi
Ingress with Wildcard TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wp-multisite-ingress
namespace: wordpress
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
ingressClassName: nginx
tls:
- hosts:
- "example.com"
- "*.example.com"
secretName: wp-wildcard-tls
rules:
- host: "*.example.com"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: wp-multisite-wordpress
port:
number: 80
Horizontal Pod Autoscaling
kubectl autoscale deployment wp-multisite-wordpress \
--namespace wordpress \
--cpu-percent=70 \
--min=3 \
--max=10
This ensures your WordPress pods scale out automatically during traffic spikes and scale back down during quiet periods.
Database Considerations
For production, use a managed database service like AWS RDS or Cloud SQL rather than running MySQL inside the cluster. This offloads backup, replication, and failover to the cloud provider. For a cost comparison, see our analysis of AWS RDS vs self-managed MySQL. Our Kubernetes management service can handle the full deployment lifecycle for you.
Running WordPress Multisite on Kubernetes gives you the scalability and resilience of container orchestration while maintaining the simplicity of a single WordPress codebase. The key is getting shared storage and Ingress routing right from the start.
Or read how we handle it in Kubernetes Management.
Related Articles
How To Start Doing SRE With SLOs And Error Budgets
You do not need a big team to start doing SRE. You need one SLO and an error budget. A practical, plain-English guide to your first Site Reliability Engineering steps, with a worked example.
Next.jsRun Your AI-Built Next.js App Like a Real Product
AI built your Next.js app. Now the hard part - running it so users trust it, Google ranks it, and your team sleeps. Here is the operator's playbook.
Next.jsMake Google Love Your Next.js Site From Day One
AI shipped your Next.js app. Now make Google notice it. A practical guide to speed, indexing, and SEO foundations that bring compounding organic traffic.