TYPO3 Kubernetes — TYPO3 that no longer clings to a single server.

No. For a 50-page brochure site with one editor, good managed TYPO3 hosting is usually enough. Kubernetes becomes interesting at one of three points: regular load spikes, several editorial tenants in one setup, or compliance requirements that demand provable separation.

Three idiosyncrasies: fileadmin needs shared storage, scheduler jobs must not run in parallel on the same pods (otherwise duplicate dispatch), and the install-tool endpoint must be cut off hard at the network level. Anyone who runs a TYPO3 cluster like any old PHP app is building in their own follow-up bugs.

For a standard TYPO3 site on a clean cluster: typically four to eight weeks, including Helm chart, persistent storage, CI/CD pipeline, monitoring stack and rollback drills. Anyone who does this ad hoc is faster; anyone who does it sustainably — so that the second site goes up in a fraction of the time — invests more once.

For a single site, often yes. For three or more sites that share cluster, monitoring and CI/CD, the ratio tips the other way. Plus: fewer person-hours for routine updates, faster rollback on errors, lower outage risk — things that rarely show up in the classical hosting TCO.

Practically all from TYPO3 9 LTS upwards, reasonably from 11 LTS, recommended 12/13 LTS. Older versions make container builds and storage setup more involved because many setups still make direct filesystem assumptions. An upgrade path alongside the cluster migration is often the cleaner solution.

First conversation about current infrastructure, load profile and compliance requirements. From that, a concrete cluster sketch: which provider, which storage strategy, which CI/CD pipeline, which monitoring building blocks. Implementation iteratively — staging first, then production, with a rollback drill before go-live.

Not necessarily — the two topics address different axes. AI-Ready CMS means: structured content delivery, retrieval-/agent-compatible endpoints, a clean data model. That works on a single server too. Cluster operations means: load, availability, tenant separation, reproducible deployments. They meet only where the same customer has to be visible in generative search and also absorb load spikes or availability requirements. In that case the cluster discipline feeds into the AI use cases — but it is not the reason to become AI-ready and not a prerequisite for it.

From our own stack: cluster-file-backend for shared storage of fileadmin (S3-compatible or object storage), frankenphp as PHP runtime in worker mode (lower startup cost per pod), keyvalue-store for Redis/Valkey cache and session sharing, typo3-config as fluent config API for caching, logging and TLS/mTLS, secret-resolver for SOPS/Vault/KMS integration. All open under MIT, all in production on our own platform — no black-box delivery. Details in the “Related open-source packages” section above.

Stateless: frontend pods, scheduler workers, indexer pods, FrankenPHP workers — you can scale them up, roll them and throw them away at will. Stateful: the database (MariaDB/MySQL/Postgres in a StatefulSet or as managed service), the file storage (S3/object store or ReadWriteMany), the session/cache store (Redis/Valkey), the Solr or OpenSearch index. Rule of thumb: anything that persists data sits outside the application deployment — then the pod pool can actually run stateless.

Two paths. First: an FAL driver with an S3-compatible backend (via our cluster-file-backend extension or an S3 FAL driver) that holds fileadmin and processed files in the bucket — renditions land there too and persist across pod restarts. Second, for legacy setups that are not migrated: a ReadWriteMany volume (NFS or CephFS) with a shared processed-file path. Important in both paths: a CDN in front (CloudFront, Fastly or a European alternative) so the bucket does not become the render machine, and identical ProcessedFileRepository configuration in every pod so the same cache keys are formed.

In the frontend, TYPO3 session handling via cookies and FE user hash stays stateless enough for every pod to resolve them. As soon as carts, multi-step forms or authenticated sessions enter the picture, the session store belongs in a central backend — Redis or Valkey via the keyvalue-store extension, with AUTH and TLS between pod and store. Sticky sessions at the ingress are a crutch that tips on the first pod reschedule; we don’t recommend them. Backend session handling runs through the separate worker pool and should share the same store.

We deploy Redis or Valkey practically always once TYPO3 is under real load — regardless of whether one or several pods are running. The primary reason is database relief and cache speed: the typo3_cache_* tables quickly become noticeable load in MySQL or Postgres because every cache read runs as an SQL query instead of coming from RAM. An in-memory store takes that pressure off and speeds up the cache paths significantly. In a multi-pod setup, a second reason joins: a central cache store is cleaner than a file cache on a ReadWriteMany volume because invalidations are atomic rather than going through filesystem locks. Valkey is the default choice since the Redis license switch to SSPL — protocol-compatible, BSD-3-Clause-licensed, available as a managed service at European providers.

We wire mTLS on four layers, because any single one would otherwise be the weakest link:

• Pod-to-pod via a service mesh — Linkerd in most setups (lightweight sidecar, mTLS by default), Istio when the platform is already there. Identity comes from the ServiceAccount, not from the pod IP.
• Pod-to-database with client certificates against MariaDB or Postgres. No password over the wire, identity via the certificate — once the certificate workload is gone, so is the connection.
• Pod-to-cache with TLS plus client auth against Redis/Valkey. AUTH alone is not enough; the certificate moves identity into the same layer as every other connection.
• Ingress-to-origin on the reverse-proxy leg (e.g. Caddy to FrankenPHP). HTTPS at the edge is standard, but between ingress controller and pod many setups still run cleartext — we consistently close that.

Certificates come from an internal CA, orchestrated through cert-manager, which binds the appropriate issuer per platform — private CA on-prem, HashiCorp Vault, AWS Private CA, Azure Key Vault. Automatic rotation typically every 24 hours. The typo3-config extension takes the certificates from the pod volume and mounts them cleanly onto the TLS endpoints of database and cache connections, so TYPO3 itself sees nothing other than the path.

Upsides: no cleartext credentials in the image, no pod identity via IP addresses, NIS-2 and sector compliance arguments on the encryption axis nearly for free. The cost: observability gets more expensive (mesh sidecar adds latency and tracing overhead), debugging needs mTLS-aware tools (linkerd tap, istioctl proxy-config). Anyone who has once lived with cleartext pod traffic does not want to go back.

A backup without a documented restore drill is hope. Practice: daily database dumps plus persistent-volume snapshots (Velero covers both Kubernetes-natively), weekly object-storage versioning, a quarterly restore drill in an isolated namespace with smoke test. Documented RPO (typically 1 hour for standard setups, 15 minutes for e-commerce) and RTO (4 hours standard, 1 hour for critical). Anyone who does not rehearse the restore once per quarter does not know in the moment of truth whether it works — and that is the moment of truth.

Standard pattern: one primary region with the write database and editorial backend, one or more read regions with read replicas or geographically distributed frontend pods that only read. CDN in front (CloudFlare, Fastly or European providers like OVHcloud) so cache hits terminate regionally. File storage either centralised with CDN pull-through or via cross-region replication of the object store. Editorial write operations emit cache-tag invalidations that are pushed to all regions through the CDN API. Failover to another region means promoting a replica to primary, not multi-master — that avoids conflict fields in the TYPO3 data model.

Four phases. First: build the cluster at the target provider, deploy the same Helm charts, attach a test domain, run smoke tests. Second: set up database replication (old primary → new replica, asynchronous or semi-synchronous), mirror file storage (object-store replication or rsync sync phase). Third: a short maintenance window, switch the database to the new primary, point DNS to the new ingress — often a 5- to 15-minute hard cutover. Fourth: the old cluster stays as a rollback anchor for two weeks, then teardown. With container-based charts and an orderly provider reset this is a two- to four-week project, not a quarter.

GitOps means: the cluster state lives in the Git repository, a controller (ArgoCD or Flux) continuously reconciles it against the live cluster. For TYPO3 this means: a Helm chart repository plus values files per stage (dev/staging/prod) in the repo, secrets encrypted via SOPS+age or pulled via External Secrets from Vault/KMS — never in cleartext, never in the image. Every change runs through a pull request with code review, every rollback is a Git revert. We use ArgoCD in most setups, Flux where the operator is already established; the choice is usually team preference rather than technically forced.

Three levers. First, llms.txt and robots.txt with clear crawl budgets and path whitelists — that addresses the bots that follow the rules. Second, ingress-side rate limiting per user agent (NGINX limit_req with user-agent key, Traefik middleware or Caddy rate-limit) so a runaway crawler does not drain the frontend pool. Third, a separate worker pool for identified AI-crawler traffic via header-based routing — the frontend pool for human users stays untouched, the crawler pool can be scaled or cut off separately. For sensitive paths (install tool, admin endpoints, internal routes) return 404/403 regardless of user agent anyway.