Drupal on Kubernetes

Shared ReadWriteMany file storage mounts one volume into every PHP pod, so Drupal's sites/default/files directory behaves as it does on a traditional server. This fits teams that want the least change to core file handling, have contributed modules that write to local paths without an object storage adapter, or run on-premises where an NFS or distributed file system is already supported by operations. The trade-off is that the storage layer becomes a shared dependency: latency on file reads, locking behavior and capacity growth all affect every replica at once. Private files still need a path outside the web root and a clear backup target.

• Access mode support: Confirm that the storage class offers ReadWriteMany and that the vendor documents its behavior under concurrent writes from many pods.
• Performance under load: Ask how file metadata operations scale when image styles generate many small files.
• Private file separation: Plan a separate volume or path for private files, with access controlled by Drupal rather than by network position.
• Backup consistency: Confirm snapshot and restore procedures for the volume, and whether they can run without pausing cron.
• Growth and quotas: Ask how capacity is expanded and whether expansion requires downtime.

Confirm the access mode, latency profile and restore procedure with the storage vendor before the design is fixed.

Object storage keeps public and private files in a bucket accessed over an S3-compatible API, typically through a contributed module that maps Drupal's file system to the bucket. Pods stay stateless, scaling and replacing them does not touch file data, and backup and lifecycle rules sit with the bucket. This fits platforms with high file counts, multiple clusters serving the same content, or a requirement to keep private files in a separately governed store. The trade-off is that Drupal must be configured to treat file paths, image derivatives and private access correctly, and some contributed modules assume local disk.

• Public and private buckets: Use separate buckets or prefixes with distinct access policies, so private documents are never reachable through public URLs.
• Signed URLs for private files: Confirm how the chosen module issues time-limited links and how Drupal's access checks still gate every request.
• Image derivatives: Decide whether generated styles are stored in the bucket or regenerated, since this changes both cost and cache behavior.
• Endpoint and region: Confirm the endpoint, region and TLS settings your storage provider supports for the module version you pin.
• Module compatibility: Check every contributed module that writes files against the object storage adapter before go-live.

Confirm the S3 compatibility level, lifecycle and versioning features, and the bucket access model with the storage provider.

A managed database service runs the database engine, backups, patching and failover under the provider's operations, while the Drupal platform connects to it over the network. This fits teams that lack a database administration function, need point-in-time recovery without building it, or want the database outside the cluster's failure domain. Drupal supports MariaDB, MySQL, PostgreSQL and SQLite according to the Drupal.org system requirements page, so the engine choice comes first. The trade-off is less control over engine tuning and extensions, plus recurring service fees and a dependency on the provider's maintenance windows.

• Engine and version: Confirm the engine and minimum version against the Drupal release you are deploying, and check contributed module requirements for that engine.
• Network path: Plan private connectivity from the cluster to the database, with no public endpoint for application traffic.
• Backup and restore: Confirm retention, point-in-time recovery window and how a restore is tested into a separate environment.
• Maintenance and upgrades: Ask how minor and major engine upgrades are scheduled and whether they require application changes.
• Connection limits: Confirm maximum connections and whether a pooler is required as the number of PHP pods grows.

Confirm the service tier, failover behavior and restore procedure with the provider in writing.

An in-cluster database runs as a stateful workload inside Kubernetes, managed by an operator or a Helm chart with persistent volumes. This fits organizations with an established database operations practice, a requirement to keep all components in one infrastructure boundary, or air-gapped environments where a managed service is unavailable. The trade-off is that the team owns backups, failover, upgrades and storage performance, and a poorly configured stateful set can disrupt the whole platform. Kubernetes stateful workloads also add scheduling and storage class concerns that a managed service hides.

• Operator maturity: Confirm the operator's upgrade path, failover mechanism and how it handles storage class changes.
• Backups outside the cluster: Store backups in a location that survives cluster loss, and test restores on a separate cluster.
• Storage performance: Confirm the volume type delivers the write latency the database needs, not only the capacity.
• Resource isolation: Set requests and limits so database pods are not starved by PHP workloads on shared nodes.
• Ownership: Name the team responsible for database patching and on-call response before deployment.

Confirm the operator's support statement and storage vendor guidance for stateful databases before choosing this option.

Drupal's default database cache works everywhere, but on Kubernetes, moving cache bins to a shared in-memory store lets every replica read the same entries and reduces load on the database. Redis or Memcache backends are the common choices, provided a contributed module or the core cache configuration is set up to use them. This fits platforms with many PHP replicas, heavy anonymous traffic or large render caches. The trade-off is an additional stateful service to run, eviction and memory sizing decisions, and cache invalidation behavior that must match the release and deployment process.

• Bin mapping: Decide which cache bins move to the external store and keep locking and lock bins on a backend that suits them.
• Eviction policy: Confirm how the store evicts keys under memory pressure and whether that causes cache stampedes.
• Persistence: Decide whether the store needs persistence or whether losing it on restart is acceptable.
• Cluster topology: Confirm the vendor's replication and failover model, and whether the module supports it.
• Deployment ordering: Plan how a cache flush or rebuild interacts with rolling deploys.

Confirm eviction, persistence and failover behavior with the cache service vendor, and test cache behavior under the expected concurrency before go-live.