The best CMS to run in Kubernetes is a platform that ships official container images, supports stateless application pods backed by externalized state (database, search, object storage), exposes Helm charts or Operators for declarative deployment, and integrates cleanly with GitOps tooling.
Platform teams evaluating this typically compare dotCMS against platforms such as Drupal, Strapi, and Payload, alongside WordPress as the common incumbent. This guide focuses on what makes a CMS genuinely Kubernetes-friendly, and how dotCMS measures against those criteria - including how to deploy it in a production cluster with Helm and GitOps.
If your platform team has standardized on Kubernetes, your CMS should match that standard, not fight it.
At a Glance
82% of container users now run Kubernetes in production, up from 66% in 2023 (CNCF 2025 Annual Survey). The same survey found 98% of organizations have adopted cloud-native technologies in some form, and 66% of organizations hosting generative AI models use Kubernetes for some or all of their inference workloads.
A Kubernetes-ready CMS must externalize state, ship official container images, provide Helm charts, support horizontal scaling, and integrate with GitOps controllers like ArgoCD or Flux.
dotCMS provides official Helm charts at github.com/dotCMS/helm-charts and documented patterns for ArgoCD-driven GitOps deployment.
For compliance-led teams running dozens or hundreds of sites on a single cluster, the deciding factors are multi-tenant governance, role-based access, and audit trails, not container size.
Section Overview
What Is a Kubernetes-Ready CMS? - the technical criteria platform teams should test before adopting.
Why Kubernetes Matters for CMS Workloads - scale, resilience, and the operational benefits cloud-native teams expect.
Core Architecture Patterns - stateless application pods, externalized state, ingress, secrets, and observability, evaluated for dotCMS.
How dotCMS Runs in Kubernetes - Helm charts, GitOps with ArgoCD, multi-site governance inside the cluster.
FAQs and Resources - direct answers and authoritative external links.
What Is a Kubernetes-Ready CMS?
A Kubernetes-ready CMS is one that runs cleanly under standard Kubernetes patterns: containerized application pods that can scale horizontally, externalized stateful services (database, search, object storage) deployed as separate workloads or managed services, declarative installation via Helm or an Operator, support for ingress controllers and service meshes, and configuration through environment variables, ConfigMaps, and Secrets.
The opposite is a CMS designed around a single long-running server with state baked into the local file system. That kind of platform can technically be containerized but loses most of what Kubernetes offers - automated scaling, self-healing, rolling updates, and declarative reproducibility. If a CMS requires shared file system access between application instances or stores critical state on local disk, Kubernetes adoption becomes painful, regardless of vendor.
Why Kubernetes Matters for CMS Workloads
Three forces drive platform teams to standardize their CMS on Kubernetes alongside the rest of their stack.
Production scale is the new default. The CNCF 2025 Annual Survey reports that 82% of container users now run Kubernetes in production, a 16-point jump from 2023, and that 98% of organizations have adopted cloud-native technologies in some form. For platform engineering teams, anything that doesn't run in Kubernetes is now an exception that requires justification.
Operational consistency reduces risk. Running a CMS under the same orchestrator, the same observability stack, the same secret manager, and the same patch cadence as the rest of the platform means fewer special cases for the on-call team and fewer compliance gaps for the audit team. A CMS that demands its own bespoke deployment model creates exactly the kind of unmanaged surface area regulators flag.
AI workloads are accelerating the trend. The same CNCF survey found that 66% of organizations hosting generative AI models use Kubernetes to manage some or all of their inference workloads. CMSes that integrate with AI services - for content generation, translation, personalization, or governance - increasingly sit alongside those workloads in the same cluster. Running the CMS outside Kubernetes makes those integrations harder to secure and observe.
Forrester senior analyst Nick Barber has described the broader trend this way: "Agile content management systems have evolved over the past 30 years to deliver modern, digital experiences that are collaborative, iterative, and satisfy both developers and practitioners." That's a general point about agile CMS architecture from Forrester's 2021 Wave evaluation, not a statement about Kubernetes specifically - but the underlying shift toward collaborative, cloud-native content platforms is the same one driving Kubernetes adoption for CMS workloads.
Core Architecture Patterns for CMS on Kubernetes
A production deployment of a CMS in Kubernetes follows a small set of well-understood patterns, evaluated below against dotCMS's architecture.
Stateless Application Pods
The CMS application container should be stateless. All persistent state - content, users, workflow state, sessions - lives in services outside the application pod. This lets Kubernetes scale the pods horizontally, replace failed instances cleanly, and roll out new versions without coordinating disk migrations.
dotCMS's application tier is stateless when configured with externalized sessions and asset storage, allowing standard Kubernetes scaling and self-healing behavior.
Externalized State
The database (Postgres, MySQL, MariaDB), search index (Elasticsearch, OpenSearch), and asset store (S3-compatible object storage) run as separate workloads or as managed cloud services. For compliance-led environments, all three typically run inside the same trust boundary as the CMS. For development, they can be deployed as StatefulSets in the same cluster.
dotCMS externalizes state cleanly to Postgres, Elasticsearch or OpenSearch, and S3-compatible object storage - either as in-cluster StatefulSets for non-production use, or as managed services (RDS, Aurora, Amazon OpenSearch) for production.
Helm Charts or Operators
Declarative installation matters. A Helm chart turns "install the CMS" into a single command with version-controlled values, enabling reproducible deployments across dev, staging, and production.
dotCMS publishes official Helm charts at github.com/dotCMS/helm-charts, covering application deployment, ingress configuration, secret references, and resource limits, with values files for development, staging, and production profiles. See Deploy dotCMS Using Helm Charts on Kubernetes for a step-by-step guide.
Ingress and TLS
The CMS exposes editorial UI and content APIs through an ingress controller (NGINX, Traefik, Istio, or a managed offering). TLS termination happens at the ingress, with certificates managed by cert-manager or a cloud provider's certificate service. dotCMS's Helm chart includes ingress configuration as part of its standard deployment pattern.
Secrets and Configuration
Database credentials, SSO client secrets, API keys, and license tokens belong in Kubernetes Secrets, ideally backed by an external secret manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Application configuration goes in ConfigMaps. Nothing sensitive belongs in the container image - this applies to any CMS running in Kubernetes, dotCMS included.
Observability
Logs flow to the cluster's logging stack (Loki, Elasticsearch, a cloud equivalent). Metrics expose through Prometheus endpoints. Distributed traces use the OpenTelemetry collector. dotCMS, as a standard Java application running in a container, works with existing observability, secret management, and policy controls without requiring special cases - horizontal scaling, self-healing, and rolling deployments work the same way they do for any other Java workload in the cluster.
GitOps
ArgoCD or Flux watches a Git repository for desired-state manifests and reconciles them against the cluster. dotCMS's reference deployment pattern uses ArgoCD to reconcile manifests from a Git repository against the target cluster: Helm packages and templates the application, and ArgoCD continuously enforces the desired state. See Managing dotCMS Helm Deployments with GitOps for the full pattern.
How dotCMS Runs in Kubernetes
Multi-site governance inside the cluster. A single dotCMS deployment in Kubernetes can host dozens or hundreds of sites under shared governance. Each site has its own permissions, workflows, and audit trail, but they all share the same upgrade path, observability stack, and compliance posture - this is what makes dotCMS relevant for organizations that would otherwise run a separate CMS instance per brand or region.
Universal Visual Editor without external dependencies. The Universal Visual Editor, used by marketers and content owners to edit pages in context, runs inside the dotCMS deployment with no external SaaS service it depends on. For air-gapped clusters or sovereignty-constrained environments, this matters: the editorial experience doesn't break when egress is locked down.
Container orchestration patterns. dotCMS runs as a Java application inside a standard container. Horizontal scaling, self-healing, and rolling deployments work the same way they do for any other Java workload in the cluster - see Container Orchestration: Running dotCMS in Kubernetes for the specifics.
Frequently Asked Questions
Can I run dotCMS on managed Kubernetes services like EKS, AKS, or GKE?
Yes. dotCMS runs on any conformant Kubernetes distribution - EKS, AKS, GKE, OpenShift, Rancher, or self-managed clusters on bare metal. The Helm charts are distribution-agnostic, and the application has no provider-specific dependencies.
What database and search backends does dotCMS need in a Kubernetes deployment?
dotCMS uses Postgres for content and configuration, and Elasticsearch or OpenSearch for content indexing. Both can run as StatefulSets inside the cluster for non-production environments, or as managed services (RDS, Aurora, Azure Database for PostgreSQL, Amazon OpenSearch) for production. Asset storage typically uses S3-compatible object storage.
Should the application tier scale horizontally?
Yes. dotCMS application pods are stateless when configured with externalized sessions and asset storage. Horizontal Pod Autoscaler can scale them based on CPU, memory, or custom metrics. The shared state - database, search, object storage - sits outside the application pods.
How does GitOps work with dotCMS?
The dotCMS Helm chart values file lives in a Git repository alongside any custom manifests. ArgoCD or Flux watches that repository and reconciles changes against the cluster. Configuration changes flow through a pull request rather than imperative kubectl commands.
Can I run dotCMS in an air-gapped Kubernetes cluster?
Yes. The container images, Helm charts, and database can all be mirrored to an internal registry. dotCMS does not require outbound calls for core operation or license validation. Verify any AI features or third-party integrations against your specific egress policy before relying on this generally.