Is Docker safe for production? Settings that matter

Short answer: yes, many companies run Docker in production. Containers are not a security boundary as strong as a virtual machine, because they share the host's kernel, so safety depends on your configuration. Run as a non-root user, use small pinned images, never mount the Docker socket into a container, drop capabilities you do not need, keep secrets out of images and update the host.

How are containers isolated?

A container is a normal process with restrictions: namespaces limit what it can see, cgroups limit what it can use, capabilities and seccomp limit which system calls it can make. All containers on a host share one kernel. A kernel bug or a bad configuration can let a process break out. A virtual machine has a stronger wall because it runs its own kernel on a hypervisor. For most business software the container wall is adequate if you do not weaken it.

What are the settings that matter most?

Do not run as root

By default, the process inside a container is root, and root in a container is closer to root on the host than people assume. Create a user in the Dockerfile.

FROM node:22-slim
WORKDIR /app
COPY --chown=node:node . .
USER node
CMD ["node", "server.js"]

Never mount the Docker socket

-v /var/run/docker.sock:/var/run/docker.sock gives the container control of the Docker daemon, which is root on the host. Some tools ask for it. Avoid it, or use a socket proxy that exposes only the calls needed.

Avoid `--privileged`

It removes most restrictions. If something "only works" with it, find the one capability or device it needs and grant just that.

Drop capabilities and block privilege escalation

services:
  app:
    image: myapp:1.4.2
    user: "1000:1000"
    read_only: true
    tmpfs: [/tmp]
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true

read_only makes the filesystem immutable except for the volumes and tmpfs you name, which stops an attacker writing tools into the container.

Use small, pinned images

Smaller images have fewer packages to be vulnerable. Pin tags to a version, or better to a digest, instead of latest, so a rebuild does not change what you run. Scan images with Trivy or Grype in CI.

Keep secrets out of images

Anything in a Dockerfile ENV or copied into a layer is readable by anyone with the image. Pass secrets at runtime through files or your orchestrator's secrets feature, and never commit .env files.

Limit resources

Set memory and CPU limits so one runaway container cannot starve the host.

What about the network?

• Publish only the ports that must be reachable, and bind internal ones to 127.0.0.1. Docker edits the firewall rules itself, and a published port can bypass your ufw rules. This surprises many people.
• Put databases on an internal network with no published port.
• Terminate TLS at a reverse proxy. See reverse proxy hardening.

What about the host and the daemon?

• Keep the host OS and Docker updated. Kernel fixes protect every container.
• Do not expose the Docker API over TCP without mutual TLS.
• Limit who is in the docker group. Membership equals root.
• Consider rootless Docker or Podman, where the daemon and containers run without root privileges.

Is Docker Compose acceptable in production?

For a single-server deployment, yes. It is what I use for small business systems. The safety comes from the settings above, restart policies, health checks and backups, not from the orchestrator. See Docker Compose in practice and the self-hosting security guide.