Docker in Production: 15 Mistakes That Will Cost You and How to Avoid Them

Docker revolutionized software deployment by making it simple to package and run applications consistently across environments. But that simplicity is deceptive. Running Docker in production requires a different mindset than running it in development. The defaults that make Docker easy to get started with are often exactly wrong for production workloads.

After working with dozens of teams running Docker in production, I have seen the same mistakes repeated over and over. Each one has cost teams hours of debugging, unexpected outages, security breaches, or performance problems. Here are the 15 most common mistakes and how to avoid them.

Mistake 1: Running Containers as Root

By default, Docker containers run as root. This means if an attacker exploits a vulnerability in your application, they have root access inside the container — and potentially on the host system if there is a container escape vulnerability. Always create a non-root user in your Dockerfile and use the USER directive to switch to it.

Add to your Dockerfile: RUN addgroup --system app && adduser --system --ingroup app app and USER app. Ensure your application files are owned by this user and your application binds to a port above 1024 (non-root users cannot bind to ports below 1024).

Mistake 2: Using the Latest Tag

The :latest tag is not a version — it is whatever was pushed most recently. Using it means your builds are not reproducible, deployments can silently change the base image, and rollbacks may not work because the image has been overwritten.

Always pin your base images to a specific version: FROM node:20.11-slim instead of FROM node:latest. For even better reproducibility, pin to a specific SHA256 digest. Tag your own images with the git commit hash or semantic version: myapp:v2.4.1 or myapp:abc123f.

Mistake 3: Not Using Multi-Stage Builds

A typical Node.js Dockerfile that installs dependencies, builds the application, and ships the result in a single stage produces images of 1 GB or more. Most of that size is build tools, development dependencies, and cached files that are not needed at runtime.

Multi-stage builds use one stage for building (with all the build tools) and a separate stage for the final image (with only the runtime). This typically reduces image size by 60 to 90 percent, which means faster deployments, less storage cost, and a smaller attack surface.

Mistake 4: Not Setting Resource Limits

Without resource limits, a single container can consume all available CPU and memory on the host, starving other containers and potentially crashing the host. Always set CPU and memory limits in your Docker Compose file or Kubernetes deployment.

Use deploy.resources.limits in Docker Compose and resources.limits in Kubernetes. Set memory limits based on your application's actual needs plus a 20 percent buffer. Set CPU limits to prevent any single container from monopolizing processor time. Monitor actual usage and adjust limits quarterly.

Mistake 5: Storing Secrets in Images

Never bake secrets (API keys, database passwords, certificates) into your Docker images. Images are stored in registries, shared between team members, and the layers can be inspected. Secrets in images are secrets that are no longer secret.

Use Docker secrets, environment variables passed at runtime, or a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler). For Docker Compose, use the secrets directive. For Kubernetes, use Kubernetes Secrets (preferably with encryption at rest) or an external secrets operator.

Mistake 6: Not Using Health Checks

Without health checks, Docker (and Kubernetes) has no way to know if your application is actually working. The container might be running but the application inside might have crashed, be stuck in a deadlock, or be unable to connect to its database. Add HEALTHCHECK instructions to your Dockerfile or configure health checks in your orchestrator.

A good health check verifies that the application can accept requests and that its critical dependencies are reachable. For a web application, this might be an HTTP GET to a /health endpoint that checks database connectivity and returns a 200 status code. Set appropriate intervals (every 30 seconds), timeouts (10 seconds), and retry counts (3 retries before marking unhealthy).

Mistake 7: Logging to Files Inside the Container

Container file systems are ephemeral — when the container restarts, the logs are gone. Even if you mount a volume, log files inside containers are difficult to aggregate, search, and monitor across multiple containers and hosts.

Instead, log to stdout and stderr. Docker captures stdout/stderr automatically and makes it available through docker logs. Use a log driver (json-file, syslog, fluentd) to forward logs to a centralized logging system like Grafana Loki, Elasticsearch, or Datadog. This makes logs searchable, alertable, and persistent regardless of container lifecycle.

Mistake 8: Not Having a .dockerignore File

Without a .dockerignore file, Docker copies your entire project directory into the build context — including node_modules, .git, .env files, build artifacts, IDE configuration, and everything else. This slows down builds, increases image size, and can leak sensitive files.

Create a .dockerignore file with at minimum: node_modules, .git, .env, *.log, .DS_Store, and any other files not needed for the build.

Mistake 9: Running Too Many Processes in One Container

The Docker philosophy is one process per container. Running your web server, background workers, cron jobs, and database in a single container makes it impossible to scale individual components, complicates logging and monitoring, and means a crash in one process can affect all others.

Separate each concern into its own container. Use Docker Compose or Kubernetes to orchestrate multiple containers that work together. Your web server, worker, scheduler, and database should each be a separate service with its own health checks, scaling policy, and resource limits.

Mistake 10: Not Scanning Images for Vulnerabilities

Your base images contain an operating system with hundreds of packages, each of which can have known vulnerabilities. Without scanning, you are deploying known security holes to production.

Integrate image scanning into your CI/CD pipeline using tools like Trivy (free and excellent), Snyk Container, or Docker Scout. Fail the build if critical or high vulnerabilities are found. Update base images monthly to pick up security patches. Consider using distroless images (Google distroless) or Alpine-based images to minimize the number of packages and the attack surface.

Mistake 11: Ignoring Docker Compose for Development Parity

If your development environment does not match production, you will discover bugs in production that you could have caught earlier. Docker Compose lets you define your entire application stack (application, database, cache, message queue) in a single file that developers can start with one command.

Maintain separate Compose files for development and production. The development file can include debugging tools, hot-reload, and relaxed resource limits. The production file should use specific image tags, health checks, resource limits, and appropriate restart policies.

Mistake 12: Not Using Restart Policies

Without a restart policy, a crashed container stays down until someone manually restarts it. In production, use restart: unless-stopped in Docker Compose or appropriate restart policies in Kubernetes. This ensures containers automatically restart after crashes, host reboots, or Docker daemon restarts.

Mistake 13: Exposing the Docker Socket

Mounting the Docker socket (/var/run/docker.sock) into a container gives that container full control over the Docker daemon — it can create, stop, and delete any container on the host, access any volume, and execute commands on the host. This is a critical security risk. Avoid mounting the Docker socket unless absolutely necessary, and if you must, use a proxy like Tecnativa's docker-socket-proxy that restricts which API calls are allowed.

Mistake 14: Not Optimizing Layer Caching

Docker caches build layers, but the cache is invalidated when any file in a COPY or ADD instruction changes. If you copy your entire source code before installing dependencies, every code change invalidates the dependency installation cache, making builds much slower than necessary.

Structure your Dockerfile to copy dependency files first, install dependencies, then copy source code. This way, dependency installation is cached and only re-runs when your dependency files (package.json, requirements.txt) change.

Mistake 15: Not Having a Backup Strategy for Volumes

Docker volumes persist data across container restarts, but they are still on a single host by default. If the host fails, the data is lost. Implement automated backups for all Docker volumes containing important data. For databases, use the database's native backup tools (pg_dump, mysqldump) to create consistent backups rather than copying volume files directly.

Building a Production-Ready Docker Workflow

The path to production-ready Docker is not about avoiding every possible mistake from day one — it is about building good practices into your workflow incrementally. Start with multi-stage builds, non-root users, and health checks. Add image scanning and resource limits. Implement centralized logging and proper backup strategies. Each improvement makes your containers more reliable, more secure, and easier to operate.

ZeonEdge provides containerization consulting and managed Docker infrastructure for businesses that want production-grade container deployments without the operational complexity. Learn more about our DevOps services.