TYPO3 on Kubernetes under IT-Grundschutz, part 8: Making TYPO3 stateless

01 — What state TYPO3 brings along

A classic TYPO3 installation keeps state in several places that a second pod cannot see:

• Sessions for frontend and backend.
• fileadmin with the editors' uploads.
• typo3temp, including _processed_ images and generated assets.
• Caches in the filesystem and in the database.
• Locks that TYPO3 sets, for example while rendering pages.
• Scheduler tasks that must run exactly once.
• Setup and migrations, such as extension:setup and database updates.

As long as only one pod runs, this hardly shows. With the second pod the odd errors begin. Users get logged out, images go missing, caches contradict each other. The rule for the cluster is therefore: the pod contains only code and configuration. Everything else lives outside.

02 — Sessions, locks and caches

Sessions and locks belong in a shared key-value store such as Valkey or Redis. For sessions, the TYPO3 core ships a Redis backend. Locks need a strategy that works across pods. The core's file-based strategies only do that with a shared filesystem. The core ships no strategy for Valkey, but it can be extended. A class of your own implements LockingStrategyInterface and is registered in ext_localconf.php via LockFactory::addLockingStrategy(). If it returns a higher priority than the file strategy's 75, the core also uses it for page rendering. Technically, a SET … NX PX with an expiry is enough. That way a crashed pod leaves no lock behind that blocks all the others. What matters is that the store itself is protected: TLS, a separate user per tenant, no connections from outside. What that looks like with mTLS on every hop is covered in part 5.

For caches there are two routes. Frequently used caches such as pages and hash can live in Valkey. Caches that have to live on the filesystem need a backend that copes with several pods. How that works without a ReadWriteMany volume is shown in TYPO3 on Kubernetes without an RWX volume. Either way, a cache flush has to reach every pod, not only the one where it was triggered.

03 — fileadmin and processed images in object storage

Every pod needs to see uploads and _processed_ images. A single ReadWriteOnce volume ties the application to one node. A ReadWriteMany network filesystem is often slow and hard to operate. Object storage such as S3 is the more robust base.

Two routes lead there. TYPO3 can talk to S3 directly through a FAL driver. Or a CSI driver mounts a bucket into the pod as a filesystem, and TYPO3 notices nothing. The second route is transparent but adds latency: every file access becomes a request to the storage. A cache in front of it is therefore mandatory, for metadata as well as for delivered files. What that looks like in practice is described in fileadmin on S3 with caching.

Buckets should be separate per tenant, with versioning and their own access role. Uploads should also be scanned for malware before they are delivered.

04 — Read-only code, setup once per release, one scheduler

Once all state lives outside, the code can be read-only. The container's root filesystem is read-only. Only selected directories are writable, for example a tmpfs for temporary files. An attacker who can execute code cannot change it permanently.

Setup and migrations run neither in the main container nor in every pod, but once per release in a hook before the rollout. A lock in the database ensures that two migrations never run against each other, and if the hook fails, the Deployment stays as it is. The pod itself only copies the code caches pre-warmed in the build and is ready within seconds. The scheduler becomes its own CronJob with concurrencyPolicy: Forbid, so no task runs twice. And the cache flush after a deployment becomes a hook that fires exactly once after the rollout. How a pod's start went from 54 to twelve seconds this way is covered in the field note on pod start.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: typo3-scheduler
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          automountServiceAccountToken: false
          initContainers:
            # same verification chain as the web pod (part 3), shortened, key volume omitted
            - name: verify-signature
              image: registry.example.org/tools/cosign@sha256:...
              args: ["verify", "--key", "/keys/release.pub",
                     "registry.example.org/typo3/site@sha256:..."]
          containers:
            - name: scheduler
              image: registry.example.org/typo3-runtime@sha256:...
              workingDir: /app
              args: ["php", "vendor/bin/typo3", "scheduler:run"]
              volumeMounts:
                - {name: app, mountPath: /app, readOnly: true}
          volumes:
            - name: app
              image:
                reference: registry.example.org/typo3/site@sha256:...
                pullPolicy: IfNotPresent

The CronJob needs the same chain as the web pod from part 3. The runtime image contains no TYPO3 code. So here too, an init container verifies the signed artefact before the kubelet mounts it as a read-only image volume. Without that step, the scheduler either does not start at all or runs code nobody has verified.

Logs go to stdout and stderr, not to files inside the container. The platform collects them, and nothing is lost when a pod disappears. The install tool stays disabled in the cluster.

Mapping to IT-Grundschutz

• APP.4.4.A4 Separation of pods: no shared state through shared volumes, every pod isolated.
• APP.4.4.A6 Initialisation of pods: verification in init containers, setup and migrations once per release before the rollout.
• APP.4.4.A21 Regular restart of pods: only a stateless pod can be replaced at any time.
• SYS.1.6.A19 Integration of data storage into containers: deliberate, per tenant, with its own role.
• SYS.1.6.A23 Immutability of containers: read-only root filesystem.
• APP.3.1 Web applications and web services: store and scan uploads in a controlled way.

Conclusion

Statelessness is the precondition for everything that follows: rolling updates, autoscaling, pods on several nodes. Sessions and locks in Valkey, files in object storage, caches with a backend that knows about several pods, setup in an init container. After that, every TYPO3 pod is replaceable, provided Valkey, object storage and the database are resilient themselves. A single Valkey without persistence signs out every editor when it restarts. The typical misconceptions on the way there are collected in Five misconceptions: TYPO3 on Kubernetes.

How to put that replaceability to work is shown in the next part: autoscaling and probes. Back to part 7: secrets without Git.