WordPress powers over 40% of the web. For hosting providers, it's the most common workload by a wide margin — and also one of the most operationally demanding. Security vulnerabilities, plugin conflicts, database corruption, and plugin-induced performance issues make WordPress accounts disproportionately expensive to support.
Running WordPress on Kubernetes — with each site in its own isolated container — changes the operational model significantly. This article explains how KubePanel handles WordPress provisioning and what the container isolation model means for WordPress-specific challenges.
Traditional WordPress Hosting Problems
On shared hosting, WordPress sites share the same PHP installation, the same server resources, and often the same database server. This creates predictable problems:
- One compromised site affects others. A WordPress site with an unpatched plugin vulnerability can be used to attack neighboring accounts on the same server.
- Resource contention. A WordPress site hit by a traffic spike or a runaway wp-cron job consumes shared CPU and memory, degrading performance for all other sites on the server.
- Plugin conflicts with PHP versions. One customer needs PHP 7.4 for a legacy plugin. Another needs PHP 8.3. Managing this on a shared server is complex.
- Database management complexity. Multiple WordPress databases on a shared MySQL server mean shared credentials risk and noisy neighbor performance issues.
How KubePanel Provisions WordPress
When you create a domain in KubePanel with the WordPress workload type, the platform handles the full provisioning automatically:
Step 1: Container and Storage
The Kopf operator creates a namespace for the domain (dom-example-com) and provisions a PersistentVolumeClaim on Linstor storage. This PVC is dedicated to this WordPress site — no other site has access to it.
Step 2: Database
The operator provisions a dedicated MySQL database and user in the shared MariaDB instance, with auto-generated credentials. These credentials are stored in a Kubernetes Secret in the domain's namespace — not in the Django database, not anywhere accessible to other domains.
Step 3: Container Deployment
A Deployment is created with three containers:
- PHP-FPM container: The WordPress runtime, based on the configured PHP version image
- nginx container: Serves static files, proxies PHP requests via FastCGI, handles TLS termination
- SFTP container: Provides file access for the site owner
Step 4: WordPress Preinstall
If the WordPress preinstall flag is set, an init container runs before the main containers start. It downloads WordPress core, runs the installer, and configures wp-config.php with the auto-generated database credentials. By the time the domain is marked Ready, WordPress is installed and the admin user is created.
Step 5: SSL and DNS
cert-manager issues a Let's Encrypt certificate via the Ingress resource. The Ingress routes HTTPS traffic to the nginx container. HTTPS is active from the first request.
The entire process — from clicking "Create Domain" to a running WordPress installation — takes under two minutes.
When KubePanel imports a WordPress database during a cPanel migration, it automatically updates wp-config.php with the new database credentials. No manual editing required.
What Container Isolation Means for WordPress
Security Containment
When a WordPress site is compromised — and given the plugin ecosystem, it happens — the blast radius is limited to that container. The attacker has access to that container's filesystem (the WordPress files) and its database credentials. They cannot read files from other WordPress sites on the cluster, because those files live on separate PVCs in separate namespaces.
This is a structural improvement over shared hosting, where a compromised account can often traverse to neighboring accounts via the shared filesystem or shared PHP process.
Per-Site PHP Version
Each WordPress site picks its PHP version independently. A site requiring the legacy behavior of PHP 8.0 runs on PHP 8.0. A site running the latest Elementor or Gutenberg blocks runs on PHP 8.3. They coexist on the same cluster without conflict.
Per-Site Resource Limits
WordPress sites are notorious for resource consumption variation. A quiet blog uses minimal CPU. A WooCommerce store during a sale can spike dramatically. Kubernetes resource limits mean a spiky WooCommerce store cannot starve other domains on the cluster — it's capped at its allocated CPU and memory.
SFTP Access Per Site
Each domain gets its own SFTP container with its own credentials and its own NodePort. SFTP access is scoped to that domain's PVC — the user can only see and modify files for that site.
For Hosting Providers: What This Means Operationally
Container-isolated WordPress hosting changes the support equation:
- Incident scope is predictable. A compromised WordPress site is a problem for one domain, not for your entire server.
- PHP updates are per-site. Telling a customer "we're upgrading your PHP to 8.3" is a five-second operation that touches nothing else.
- Resource complaints are diagnosable. Kubernetes metrics show per-domain CPU and memory usage. You can immediately see if a site is hitting its limits.
- Backups are per-site. KubePanel's backup system creates a VolumeSnapshot of each domain's PVC plus a mysqldump of its database. Restoring one WordPress site doesn't touch others.
The cPanel migration tool handles WordPress sites specifically — it detects WordPress installations and automatically updates wp-config.php with new database credentials after import. No manual intervention needed for migrated WordPress sites.