Docker for Production Web Applications: Practical Guide

Docker for Production Web Applications

Docker can run production web applications reliably, but docker compose up -d is not, by itself, a production strategy. The difficult part is not starting containers. It is making sure those containers can be rebuilt predictably, survive failures, avoid exposing unnecessary privileges, preserve important data, stay within resource limits, produce usable logs, and be replaced safely during deployments.

For a small or medium web application on a single server, Docker Compose can be a perfectly reasonable production deployment model. Docker explicitly documents Compose for single-host production deployments. As infrastructure grows across multiple machines, however, scheduling, failover, service discovery, rolling deployments, and orchestration become separate architectural concerns.

Direct Answer

Docker is suitable for production when containers are treated as disposable runtime units rather than miniature servers. Build immutable images, run applications with the least privilege they require, persist state outside the container layer, configure health checks and restart behavior, constrain CPU and memory, rotate or export logs, protect secrets, expose only necessary ports, and maintain tested backup and deployment procedures.

Docker provides most of these primitives. Production reliability comes from configuring them correctly.

Production Essentials

Build Production Images

A production image should contain what the application needs to run, not everything that was required to build it.

Docker recommends multi-stage builds for separating compilers, development dependencies and build tooling from the final runtime image. Smaller runtime images generally contain fewer unnecessary dependencies and reduce the available attack surface. Docker also recommends trusted, minimal base images and periodically rebuilding images so updated dependencies can be incorporated. (docs.docker.com)

A typical pattern looks like this:

# syntax=docker/dockerfile:1

FROM node:24-alpine AS build

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build


FROM node:24-alpine AS runtime

WORKDIR /app

ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force

COPY --from=build /app/dist ./dist

USER node

EXPOSE 3000

HEALTHCHECK --interval=30s \
  --timeout=3s \
  --start-period=10s \
  --retries=3 \
  CMD wget -qO- http://127.0.0.1:3000/health || exit 1

CMD ["node", "dist/server.js"]

This is an illustrative Node.js example rather than a universal Dockerfile. The important pattern is the separation between build and runtime stages, installation of production-only dependencies, execution as a non-root user, and an application-level health endpoint.

Docker recommends using USER when a service does not require root privileges. (docs.docker.com)

Pinning Images

Image tags are mutable. An image such as:

FROM alpine:3.21

may resolve to a different underlying image after its publisher releases an update.

Docker supports pinning an image by digest:

FROM alpine:3.21@sha256:...

This improves reproducibility because the same digest identifies the same image content. The tradeoff is important: strict digest pinning also means updates do not arrive automatically. A sensible production process combines controlled pinning with automated dependency-update checks rather than permanently freezing old images. (docs.docker.com)

INTERNAL LINK: How Docker Images and Layers Work

Keep Secrets Out

Passwords, private tokens and credentials should never be baked into an image.

Docker specifically warns against using Dockerfile ARG or ENV for build secrets because those values can persist in the resulting image or its metadata. BuildKit secret mounts make credentials temporarily available during a build without storing them in the final image. (docs.docker.com)

Docker Compose also supports runtime secrets. On Linux containers, those secrets can be mounted as files under /run/secrets/ and granted only to services that require them. (docs.docker.com)

The deeper principle is simple: configuration may change between environments, while the application image should not need to contain the credentials for those environments.

Limit Container Privileges

Containers provide isolation, but they are not an excuse to ignore host security.

Access to the Docker daemon is especially sensitive. Docker's documentation warns that users capable of controlling the normal rootful Docker daemon can effectively obtain root-level capabilities on the host. Membership in the docker group therefore needs to be treated as privileged access. (docs.docker.com)

For web applications:

• run the application as a non-root user when possible;
• avoid privileged: true;
• drop capabilities the application does not require;
• retain Docker's default seccomp protection unless there is a specific, understood reason to change it;
• consider no-new-privileges;
• consider Rootless Docker where its operational limitations are acceptable.

Docker's rootless mode runs both the daemon and containers without root privileges, reducing the impact of some daemon or runtime vulnerabilities. (docs.docker.com)

Docker also recommends removing unnecessary Linux capabilities rather than adding broad privileges. (docs.docker.com)

Control CPU and Memory

A container has no resource constraints by default. Unless limits are configured, it can consume as much CPU or memory as the host allows. One runaway application can therefore affect other containers running on the same machine. (docs.docker.com)

Compose supports controls such as:

services:
  app:
    image: registry.example.com/app:1.4.0

    cpus: 1.0
    mem_limit: 512m

Those numbers should not be copied blindly. Measure normal workload, expected traffic, runtime memory behavior and failure conditions first. A PHP-FPM service, JVM application, Node.js process and PostgreSQL server can require very different limits.

The purpose of limits is isolation and predictable failure behavior, not simply making every container use less memory.

Persist Important Data

The writable container filesystem is temporary. When the container is removed, data stored only in that writable layer disappears. (docs.docker.com)

Persistent application data should instead live in Docker volumes, suitable bind mounts, object storage, or external database/storage services.

Docker describes volumes as its preferred mechanism for persistent container data in many scenarios. Volumes exist independently of an individual container and can be backed up, restored and migrated. (docs.docker.com)

That creates an important architectural distinction:

Container = replaceable application runtime

Volume or external service = persistent state

A volume alone is not a backup. Production systems still need scheduled backups and, more importantly, tested restoration procedures.

INTERNAL LINK: Docker Volumes Explained

Health and Recovery

A process can still be running while the application itself is unusable.

Docker's HEALTHCHECK instruction allows an image to define a command that tests whether the application is actually functioning. Docker then exposes states such as starting, healthy and unhealthy. (docs.docker.com)

For a web service, /health might verify that the HTTP application can answer requests. More advanced readiness checks may also verify dependencies, although a health endpoint should avoid becoming so complex that a temporary external failure creates unnecessary restart loops.

Compose can also wait for a dependency marked service_healthy before starting another service. (docs.docker.com)

Restart policies solve a related problem:

restart: unless-stopped

Docker documents always, unless-stopped and on-failure policies for automatically restarting containers after exits or daemon restarts. (docs.docker.com)

A restart policy improves recovery from process failure. It does not replace monitoring or fix an application that continuously crashes.

Control Network Exposure

Published Docker ports require deliberate attention.

For example:

docker run -p 3000:3000 myapp

publishes the port on all host interfaces by default. Docker documentation explicitly notes that such published ports can become externally accessible. (docs.docker.com)

If a reverse proxy on the same server is the only service that should reach the application, binding to loopback can reduce unnecessary exposure:

ports:
  - "127.0.0.1:3000:3000"

Databases, Redis instances and internal queues usually should not be publicly published merely because they run in Docker.

INTERNAL LINK: Reverse Proxy Architecture Explained

Do Not Ignore Logs

Docker's default json-file logging driver does not perform log rotation by default. A noisy application can therefore consume significant disk space over time. Docker recommends considering the local logging driver to help prevent disk exhaustion. (docs.docker.com)

A production setup should deliberately choose between:

• local logs with rotation;
• a logging driver sending logs elsewhere;
• an external observability system.

Whatever method is selected, logs should survive long enough to investigate failures without eventually filling the server's disk.

A Practical Compose Baseline

A hardened application service might begin with something like:

services:
  app:
    image: registry.example.com/myapp:1.4.0
    restart: unless-stopped

    ports:
      - "127.0.0.1:3000:3000"

    cpus: 1.0
    mem_limit: 512m

    read_only: true

    tmpfs:
      - /tmp

    security_opt:
      - no-new-privileges:true

    cap_drop:
      - ALL

    logging:
      driver: local

This is a starting point, not a universal template. read_only: true can break applications that expect writable directories, and dropping every capability can break software that genuinely needs one. Production hardening should therefore follow least privilege, not maximum restriction regardless of application behavior. Compose supports these service-level controls directly. (docs.docker.com)

Common Production Mistakes

The most common Docker production problems are rarely caused by containers themselves. They usually come from deployment choices: running as root unnecessarily, using mutable latest tags without controlled updates, storing database data inside the container layer, publishing internal ports publicly, having no memory limit, placing credentials in images, allowing logs to grow indefinitely, or treating container restart as a substitute for monitoring.

Another common mistake is mounting the application source directory from the host in production. Docker's production Compose guidance specifically suggests removing development-oriented code bind mounts so deployed application code remains inside the image. (docs.docker.com)

When Compose Is Enough

Docker Compose is a reasonable production option when one host is sufficient and the team can tolerate that host as an infrastructure boundary.

A setup consisting of a reverse proxy, application containers, Redis and perhaps a database can remain operationally simple this way.

The requirements change when you need automatic scheduling across machines, node-level failover, large-scale service discovery, coordinated rolling deployments or extensive horizontal scaling. At that point the question is no longer whether Docker works in production. It is which orchestration platform should manage the containers.

INTERNAL LINK: Docker Compose vs Container Orchestration

SeoNest Recommendation

Treat Docker production deployment as a system rather than a Dockerfile.

The minimum useful production model is:

source code → CI build and test → immutable image → registry → controlled deployment → health verification → monitoring → rollback

Keep persistent state outside replaceable application containers. Restrict privileges and exposed ports. Define resource limits based on measurement. Protect credentials independently from images. Automate backups and test restores.

Docker simplifies packaging. Production engineering is what makes that package reliable.

FAQ

Is Docker Compose safe for production?

It can be. Docker officially documents Compose for production and single-host deployments. Whether it is appropriate depends on the application's availability, scaling and operational requirements.

Should containers run as root?

Only when the application genuinely requires those privileges. Docker recommends using USER for services that can operate without root. (docs.docker.com)

Should I use latest in production?

A mutable tag makes exact deployment reproduction harder. Versioned tags or digest pinning provide greater control, provided updates are actively maintained. (docs.docker.com)

Do Docker volumes need backups?

Yes. Volumes provide persistence outside the container lifecycle; they do not automatically provide disaster recovery.

Does restart: always make an application highly available?

No. It can restart a failed container on the same Docker host. It does not protect against host failure and does not diagnose why the application failed.

Final Takeaway

Docker is not production-ready because a container starts successfully. It becomes part of a production-ready system when images are reproducible, privileges and resources are controlled, state is protected, failures are detectable, logs are managed, network exposure is deliberate, and deployments can be recovered or rolled back.

The container is the replaceable part. The production architecture around it is what provides reliability.

Sources

1. Docker — Building best practices. Docker Build best practices
2. Docker — Use Compose in production. Compose in production
3. Docker — Docker Engine security. Docker Engine security
4. Docker — Rootless mode. Docker Rootless mode
5. Docker — Resource constraints. Docker resource constraints
6. Docker — Configure logging drivers. Docker logging drivers
7. Docker — Volumes. Docker volumes
8. Docker — Build secrets. Docker build secrets
9. Docker — Dockerfile reference. Dockerfile reference
10. Docker — Port publishing and mapping. Docker port publishing