Running containers securely starts with a handful of well-known practices. Containers should run as a non-root user, set via the USER instruction in the Dockerfile. Base images should be minimal, such as alpine, slim Debian variants, or distroless images, to reduce both attack surface and image size. Image layers should be scanned for vulnerabilities with tools like docker scout. Secrets should never be baked into image layers; instead, pass them at runtime with -e or env_file, or use BuildKit's --mount=type=secret during the build. The --read-only flag mounts the container's root filesystem as read-only so that only tmpfs and explicit volume paths can be written to, which is a strong hardening technique. Dropping Linux capabilities that the container does not need further narrows the surface: Docker keeps a small safe set by default and exposes --cap-add and --cap-drop for tuning.
A few options deserve special caution. --privileged gives the container almost all host capabilities and access to all devices, disabling most security barriers, which is useful for nested Docker-in-Docker setups but a major risk in production. The --security-opt flag enables additional protections: no-new-privileges prevents setuid binaries from gaining new privileges, while seccomp and apparmor options load custom security profiles. Docker's default seccomp profile allows about 300 syscalls and blocks the rest. The userns-remap setting in daemon.json maps container UIDs to a range of unprivileged host UIDs, so that even a container running as root does not yield host root in the event of an escape.
Resource limits are essential for stable multi-tenant systems. docker run --memory=512m caps memory, --cpus=1.5 limits CPU usage, --pids-limit caps process creation (defending against fork bombs), --shm-size enlarges /dev/shm beyond its default 64 MB (which fixes shared-memory errors in Python multiprocessing and some ML workloads), and --ulimit nofile=65535:65535 raises the open-file limit beyond the default 1024. In Compose, these are expressed under deploy.resources.limits. Restart policies control what happens on exit: no (do not restart), on-failure (only on non-zero exit), always (always restart, even after docker stop), and unless-stopped (always except after a manual stop).
A HEALTHCHECK instruction or flag gives Docker a way to test whether the container is genuinely working, distinguishing "running" (the main process is alive) from "healthy" (the healthcheck reports 0), which orchestrators use to gate dependent services. Signal handling deserves attention as well: PID 1 inside a container ignores SIGTERM by default unless the process is signal-aware, which is why exec form is preferred for CMD and ENTRYPOINT and why --init (which injects tini as PID 1) is recommended for most images. Log rotation is another operational concern: the default json-file driver has no rotation and can fill the disk, so configuring max-size and max-file log-opts in daemon.json keeps usage bounded.