TYPO3 on Kubernetes without an RWX volume — why I do without a shared filesystem

TL;DR

Many TYPO3 clusters run on a shared filesystem — usually because that was the norm in classic hosting environments. For the TYPO3 cache it is unnecessary in most cases: the cache does not need a shared file, but a cluster-wide consistent view of whether an entry is valid. Separate the two — metadata centralised, cache files local per pod — and the RWX volume disappears for this use case: less infrastructure, faster pods, one fewer point of failure. Important distinction: this concerns the cache, not persistent user data like fileadmin or processed images — those belong in object storage via FAL, not on an RWX volume.

Classic TYPO3 operations

Historically TYPO3 ran on a single server, and a local filesystem was a given: cache files, temp files and the PHP code all sat on the same disk. There was exactly one server and therefore exactly one view of the filesystem — questions of synchronisation never arose. That self-evidence is precisely why it is so rarely questioned later: it was never a decision, just a given.

The first Kubernetes cluster

As soon as TYPO3 is distributed across several pods, a new question appears: what happens to files a pod generates at runtime? The usual answer is a reflex — “we need a shared filesystem” — and NFS, AWS EFS, Azure Files, CephFS or GlusterFS is introduced. At first glance that works. At second glance a new, permanent dependency appears — introduced to solve a problem that was never precisely named beforehand.

The actual problem

A shared filesystem solves the synchronisation question but creates four new themes that demand attention permanently in operations.

Higher latency

A local file access takes microseconds. A network filesystem needs additional network and storage operations for the same file. For a cache-heavy CMS that reads and writes many small files, this adds up noticeably.

More complex infrastructure

With the shared filesystem comes another critical building block in the stack — including monitoring, backup, security hardening and high availability. That is not a one-off effort but a component that from now on wants to be operated alongside everything else.

Single point of failure

If the shared filesystem fails, usually all TYPO3 pods are affected at once. The architecture meant for resilience thereby gains a central spot where exactly that resilience tips over.

Higher cost

With cloud providers in particular, RWX-capable volumes are noticeably more expensive than local block or ephemeral storage classes — a running cost that grows with every environment.

Does TYPO3 really need a shared filesystem?

I asked this concretely for the platforms I manage. The surprising answer: for many cache use cases, no. The fallacy sits in how the requirement is phrased. It usually reads, implicitly, “all pods must own the same cache file” — but what is actually meant is “all pods must know whether a cache entry is valid”. These are two different problems, and only the second strictly requires shared state.

A different architecture: metadata centralised, payloads local

Instead of storing the cache files centrally, I separate two things that historically sat in the same filesystem.

Cache metadata

Keys, tags, expiry times and invalidation information. This state must be identical cluster-wide, but it is small and structured — exactly what a central store (a database or Redis, say) manages well and fast.

Cache payloads

The actual cache files. They can live locally in each pod. If a file is missing in a pod, it is simply regenerated there. The shared state stays where it belongs — in the metadata — and the large, frequent reads/writes stay local and fast.

Deterministic re-materialisation

The decisive idea behind it: a cache file is not a business object but a reproducible intermediate result. When a pod restarts or is missing a file, it can regenerate it from the source data and the central metadata. Losing a cache file is therefore not data loss but at most a one-off recomputation. Exactly this property — losslessness through reproducibility — lets you treat pods as interchangeable instead of binding them to a shared volume.

What it gained us in operations

For the TYPO3 platforms where I implemented this, it means concretely: no more RWX volume for the cache, instead fast local storage classes per pod, pods that can be regenerated and scaled at will, and yet a cluster-wide consistent cache invalidation via the central metadata. One fewer component in the critical path also means one fewer component in monitoring, backup and incident operations. This very consideration is where the Cluster File Backend for TYPO3 came from, which I develop and maintain — the clean implementation of separating metadata from payloads.

When a shared filesystem is still the right choice

This architecture solves the cache case — it is not a blanket “RWX is unnecessary”. Persistent, non-reproducible data still needs shared, durable storage. In TYPO3 that is mainly fileadmin, user uploads and processed images (_processed_). For this class my recommendation is usually not an RWX volume but object storage via FAL (S3-compatible) — lossless, scalable and without the shared-filesystem layer. Separate the two cleanly — reproducible cache local, persistent assets in object storage — and most TYPO3 clusters get by entirely without an RWX volume.

Conclusion

A shared filesystem is not automatically the best solution for TYPO3 on Kubernetes — often it is just the one carried over from the single-server era. Separate cache metadata from cache files and put persistent assets in object storage, and you operate your cluster more simply, more cheaply and with one fewer point of failure. The question is rarely “which RWX volume?” but “which of this data really needs shared state — and which only needs to be reproducible?”