In an era of click-and-build website platforms like Squarespace and GoDaddy, it is easy to forget that convenience often comes at the cost of control. Hosting WordPress on Kubernetes is one of the clearest ways to reclaim that control — and this post explains exactly what that means in practice.

If you are building a serious business, especially a technical one, hosting your own WordPress instance on Kubernetes can provide a level of flexibility, resilience, and ownership that hosted platforms cannot match.

This post covers why Kubernetes-hosted WordPress is fundamentally different, when it makes sense (and when it does not), the operational responsibilities involved, a production-ready approach on Civo, a storage philosophy that supports future growth, and why I recommend direct Kubernetes manifests rather than Helm for WordPress.

The Core Difference: Platform vs Infrastructure

Hosted platforms give you a curated experience. Kubernetes gives you infrastructure control.

Hosted website platforms typically provide managed hosting and updates at the platform layer, built-in themes and design tools, a limited or tightly controlled plugin ecosystem, no server-level access, limited ability to integrate with your broader systems, and vendor lock-in.

They are excellent for brochure sites and rapid marketing pages, but they can limit plugin freedom, custom integrations, performance tuning, data ownership and portability, and security controls that go beyond what the platform supports.

With Kubernetes-hosted WordPress, you operate WordPress as an application on infrastructure you control. That unlocks full WordPress capability and lets the site evolve with your business.

What You Gain with WordPress on Kubernetes

When you deploy WordPress yourself, you gain full access to the WordPress plugin ecosystem, full database control including ownership of your content and data model, network and security control through Ingress, WAF options, headers, and rate limits, TLS automation and renewals with cert-manager, CI/CD integration and Infrastructure-as-Code workflows, horizontal scaling, and a path to multi-node and higher availability designs.

For many technical businesses, that control is not a luxury. It is a strategic advantage.

The Responsibility Trade-Off

Control comes with responsibility. If you self-host WordPress, you must treat it like production infrastructure.

You must keep WordPress core updated, update plugins frequently and remove abandoned plugins, patch base container images, maintain database health and capacity, monitor TLS certificates and renewal paths, implement backups and test restores, and monitor resource usage and performance.

Kubernetes does not remove operational work. It makes the work more structured and automatable.

Why Kubernetes Instead of a Traditional VPS

A traditional VM is a valid option and can be simpler initially. Kubernetes becomes compelling when you want repeatability and a clear path to growth.

Kubernetes provides declarative configuration where your site is defined as code, self-healing through restart and reschedule behaviors, standardized networking patterns, consistent deployment workflows across dev, staging, and production, easier integration with modern security and backup tooling, and a clean scaling story.

In other words: you are building a platform, not just hosting PHP.

Architecture Overview: Medium Single Node on Civo

This design starts with a cost-efficient single node, but avoids choices that trap you there later.

The initial design goals include a single node for cost efficiency, a medium-size instance to avoid resource pressure, production-ready TLS, storage choices that support future multi-node expansion, and direct Kubernetes manifests with no Helm abstraction.

In a follow-up post, I will publish production-ready YAML manifests and host them in a public Git repository.

Storage Philosophy: Design for Scale from Day One

A common mistake with Kubernetes WordPress tutorials is binding your site to node-local storage. That works until you add a second node or the pod reschedules. Then your data is stuck in the wrong place.

The core principle: avoid node-local storage paths for anything you must keep.

Instead, prefer CSI-backed block storage using cloud volumes, a StorageClass designed for portability, and a clear migration path to a ReadWriteMany solution later such as NFS, Ceph, or Longhorn.

WordPress is stateful. The goal is to isolate state in places you can protect, back up, and move.

Database Strategy: Separate the Database from WordPress

Do not bundle MySQL inside the WordPress container.

Deploy MySQL or MariaDB separately with Kubernetes Secrets for credentials, a stable internal Service name, persistent storage on CSI-backed volumes, and a backup strategy that does not depend on the WordPress pod.

This lets you upgrade, backup, and troubleshoot the database independently.

Direct WordPress Deployment: Why Not Helm

Helm is powerful, but it also introduces abstraction and version drift that can make debugging harder, especially for smaller deployments.

For a straightforward WordPress stack, direct manifests are easier to read and reason about, reduce hidden defaults, keep the configuration explicit and auditable, and make troubleshooting more direct.

My recommendation is to use direct Kubernetes manifests for WordPress, and reserve Helm for components where charts are truly mature and widely standardized, such as some ingress controllers.

TLS and Ingress

Use Traefik or NGINX as your ingress controller, cert-manager for certificate automation, and Let’s Encrypt with a ClusterIssuer.

The flow is straightforward: Internet to LoadBalancer to Ingress Controller to WordPress Service to Pod. TLS is terminated at ingress. Certificates are auto-renewed. No manual certificate management required.

Backups: The Most Important Section

If you self-host, backups are your responsibility.

Database backups: Schedule mysqldump jobs or logical backups, store them off-cluster in object storage or NAS, and periodically test restores.

wp-content backups: Snapshot block storage or rsync to external storage. Treat wp-content as the key persistent WordPress asset.

Full cluster backup: Velero is the recommended tool to capture cluster state and persistent volume backups where supported.

A WordPress site without tested restores is not a backup plan. It is hope.

Performance and Scaling Strategy

Start simple with one WordPress replica, one database replica, and a single node.

Scale deliberately. Add object caching with Redis when you need it. Introduce Horizontal Pod Autoscaling for WordPress when the app is stateless enough. Move the database to a managed service or HA architecture as load grows. Add nodes and move toward higher availability.

If you made smart storage choices early, growth does not require re-architecture.

When This Approach Makes Sense

This approach is ideal for technical founders and technology-forward businesses, SaaS companies that want tight integration and ownership, consulting firms who want their infrastructure to reflect their standards, and organizations requiring specific plugins and customization.

It is not ideal for non-technical solo site owners who want zero maintenance, or teams without an ops mindset or without a partner who provides it.

The Real Advantage: Strategic Control

Hosting WordPress on Kubernetes is not about saving money. It is about control, ownership, and an architecture that can evolve.

Squarespace builds websites. Kubernetes builds platforms.

If your business depends on technology, your website should not live inside a walled garden you cannot fully control.