What does mounting `tmpfs` inside a container buy you for secret material, and how do Docker Compose and Swarm `secrets:` entries actually deliver a value into a container?

## tmpfs, precisely `tmpfs` is a Linux filesystem that lives in page cache — memory, with pages eligible for swap unless swap is off or the memory is locked. Mounting it into a container gives a writable path whose contents never touch the container's copy-on-write layer or a host directory. That matters for secrets in three ways: an image built from a running container (`docker commit`) cannot capture it; `docker diff` does not report it, so it will not sneak into an exported artifact; and container removal destroys it, so no cleanup step can be forgotten. Use the standard hardening options: `noexec` and `nosuid` (nothing there should be executable), `mode=0700` so only the intended uid can traverse it, and `size` to bound the memory a container can consume this way — without a size limit a container can pin a large amount of host memory. The typical pattern: an entrypoint or init sidecar authenticates with a workload identity, fetches the credential, writes it into the tmpfs path, and the application reads that path. Nothing durable ever exists. ## Compose secrets Compose supports a top-level `secrets:` block with a `file:` source (or `environment:`, taking the value from a variable in the shell running Compose), referenced by services. Each referenced secret appears in the container at `/run/secrets/<name>`, read-only. The long syntax lets you override `target`, `uid`, `gid` and `mode`, which matters when the app runs as a non-root user. Be honest about what this is on a single host: the source is a plain file on your disk and Compose mounts it. It buys a **consistent shape** — files at `/run/secrets`, matching the `*_FILE` convention official images use — not encryption at rest. Its value is that the same manifest works when that shape is backed by a real secret store elsewhere. ## Swarm secrets In Swarm mode the object is managed by the cluster. `docker secret create db_password ./file` stores it in the raft log, **encrypted at rest** (the raft log is encrypted, and the cluster can be locked with an unlock key so the keys are unavailable after a restart without it). When a task referencing the secret is scheduled, the manager sends the value **only to that node** over the cluster's mutual-TLS channel, and the value is mounted into the task container on an in-memory filesystem at `/run/secrets/<name>`. It is never written to the node's disk, and when the task stops the node discards it. Operational properties worth naming: secrets are **immutable** — you cannot update one in place, so rotation is `docker secret create db_password_v2` followed by `docker service update --secret-rm db_password --secret-add db_password_v2`, which rolls tasks; access is per-service, so a compromised service only sees what it was granted; and secrets are size-limited (on the order of half a megabyte), so they are for credentials and small certificates, not bulk data. ## Where this fits Swarm has faded relative to Kubernetes, so treat the Swarm detail as background rather than a core skill — but the *shape* is exactly what other platforms adopted: a small managed object, delivered only to the workloads that need it, mounted as a file on an in-memory filesystem, and rotated by replacement. Explaining that shape, and why tmpfs is the right backing for it, is what the question is really testing.