The 5 biggest misconceptions about running TYPO3 on Kubernetes
Running TYPO3 on Kubernetes is technically unproblematic today. What makes projects needlessly expensive and fragile is rarely a technical limit — it's assumptions carried over unchanged from the classic hosting world. In practice I keep running into the same five. This article names them and shows how to tell whether Kubernetes is the right path for a TYPO3 project at all.
What this is about
The following five misconceptions come up regularly in TYPO3-on-Kubernetes projects — across industries and team sizes. None of them is a TYPO3 problem. All arise because an assumption that was correct in the single-server world migrates, unexamined, into a distributed platform. Question them, and you operate your platform more simply, more robustly and more cost-efficiently.
Misconception 1: TYPO3 strictly needs a shared filesystem
This is the most common assumption — and the reflex to immediately pull in NFS, EFS or CephFS. In fact the cache in particular needs no shared filesystem: it is enough to keep the cache metadata centralised (database or Redis) while the actual cache files are created locally in each pod and regenerated on demand. Persistent assets like fileadmin or processed images belong in object storage via FAL anyway, not on an RWX volume. That removes the most expensive and most fragile component for most clusters. (I described this in detail in the sibling article on the RWX-free TYPO3 cluster.)
Misconception 2: Kubernetes makes TYPO3 highly available automatically
Several pods are not the same as high availability. As long as central building blocks like the database, Redis, storage or DNS remain single points of failure, the outage risk stays exactly there. Kubernetes reliably distributes the low-state parts — but it makes no component highly available that was not designed to be. High availability is a property of each individual critical component, not a by-product of the orchestrator.
Misconception 3: More pods automatically mean more performance
TYPO3 applications are rarely CPU-bound. The real bottlenecks usually sit elsewhere: in expensive database queries, in Solr, in external APIs or in a slow filesystem. More pods scale the application layer — but they fix no bottleneck that sits one layer deeper. Scale without measuring and, in the worst case, you only multiply the load on the same overloaded database server.
Misconception 4: Containerisation is already cloud-native
A Docker container does not make an application cloud-native. Cloud-native means, among other things: reproducible deployments, horizontal scalability, low-state services and automated recovery. Between “runs in a container” and “is cloud-native” lies exactly the work that later decides operational calm — such as the question of which state belongs where (see misconception 1). A container is the packaging, not the architecture.
Misconception 5: Kubernetes pays off for every TYPO3 project
Not every project needs Kubernetes. For a single website or a small landscape, a well-run server is often the more economical and calmer solution. Kubernetes plays to its strengths only when several environments, many deployments, real availability requirements and a DevOps-oriented team come together. Introduce Kubernetes without those drivers and you mostly buy complexity that nobody needs.
When Kubernetes really makes sense
Kubernetes becomes interesting as soon as infrastructure is understood as a platform — a reusable, standardised foundation for many projects rather than a one-off per website. That is when the real benefits appear: standardised, reproducible deployments, automated scaling and higher operational reliability, because the same path is always taken. For larger TYPO3 landscapes this is often the point where the effort clearly pays off. My rule of thumb: Kubernetes pays off when the platform carries more than one project.
Frequently asked questions
Does TYPO3 on Kubernetes need a shared filesystem?+
For the cache, usually not — metadata centralised, cache files local per pod. Persistent assets (fileadmin, _processed_) belong in object storage via FAL, not on an RWX volume.
Is TYPO3 automatically highly available with several pods?+
No. Database, Redis, storage and DNS must each be designed for high availability. Kubernetes distributes the low-state parts but does not replace an HA concept for the central components.
Do more pods solve performance problems?+
Only if the bottleneck is in the application layer. More often the brakes sit in database queries, Solr, external APIs or the filesystem — scaling pods does not help there.
Does Kubernetes pay off for a single TYPO3 project?+
Usually not. A well-run server is often more economical for a single website. Kubernetes pays off when the platform carries several environments, many deployments and real availability requirements.
Conclusion
TYPO3 works excellently on Kubernetes. Most difficulties arise not from TYPO3 but from assumptions carried over from classic hosting environments and never re-examined. Question those assumptions — starting with which state really has to be shared — and you design your platform more simply, more robustly and more cost-efficiently. And whoever honestly checks whether Kubernetes is the right path at all makes the more economical decision, whichever way it goes.
Before you build a cluster nobody needs — let's talk about your actual requirements.
I tell you honestly whether Kubernetes moves your TYPO3 project forward — or only makes it more expensive.
A reality check for TYPO3 on Kubernetes: I test assumptions against your actual load, name the real bottlenecks (database, Solr, storage) and build a platform that holds — or advise against a cluster, with reasons, when a server is the better choice.
Platform operations instead of advice-on-paper: I analyse, build and operate TYPO3 platforms along actual need — not along the trend.
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.
![[Translate to English:] Foto von Kai Ole Hartwig.](/fileadmin/_processed_/e/9/csm_ole-neu_8000c3dfab.avif)