A city permit portal runs a container that writes uploaded PDFs under /tmp/uploads. After a redeploy the files are gone. What should the developer use so those uploads survive container replacement?

Permit-portal uploads must outlive the container that accepts them. A Docker volume (and later a Kubernetes volume or PersistentVolumeClaim) mounts durable storage at the upload path so files live outside the container’s ephemeral writable layer. When the city redeploys and replaces the process, the volume remains; the new container simply remounts the same path and finds the PDFs still there. That separation is the durable pattern: treat the process as disposable and keep municipal artifacts on storage that is not tied to one container instance.

Baking uploads into an image with docker commit after each night turns every night’s files into a snowflake layer. Images should be reproducible build artifacts, not ad-hoc snapshots of live data; commit also bloated registry history and breaks the rebuild-and-replace workflow. Relying on the writable layer because “Docker persists it” misunderstands the model: that layer is discarded when the container is removed, which is exactly what redeploy does. Storing PDFs only in the process heap and serializing on SIGTERM is fragile for large uploads, loses data on crash or SIGKILL, and still does not provide shared durable storage across replacements.

Exam caveat: a named volume on one Docker host is not the same as a multi-node shared filesystem—OKE still needs the right volume type and access mode when pods move across nodes. Operational check: after a deliberate redeploy, list the upload directory inside the new container and confirm yesterday’s permit PDFs are present on the mounted volume path, not only on a leftover writable-layer path.