Docker has been mainstream for over a decade now. We should have figured it out by now. And yet, I keep seeing the same container mistakes in production — at startups, at enterprises, at companies that should absolutely know better.
Here are the 5 most common Docker mistakes I still encounter in 2026, and what to do instead.
<h2>Mistake 1: Running as root inside containers</h2>
This is still the #1 security issue I see in container audits. Your Dockerfile doesn’t specify a user, so everything runs as root. Inside the container, this means a vulnerability in your app gives an attacker root-level access to the container filesystem, and potentially a path to escape to the host.
The fix:
<pre><code class="language-dockerfile">FROM node:22-slim
RUN groupadd -r appuser &amp;&amp; useradd -r -g appuser appuser
WORKDIR /app
COPY --chown=appuser:appuser . .
RUN npm ci --production
USER appuser
CMD [&quot;node&quot;, &quot;server.js&quot;]
</code></pre>
Always create a non-root user. Always switch to it before CMD. This takes 2 lines and prevents an entire class of attacks.
<h2>Mistake 2: Using latest tags in production</h2>
<code>FROM node:latest</code> is a time bomb. Your build works today. In 3 months, <code>latest</code> points to a new major version. Your build breaks — or worse, it succeeds but your app behaves differently.
The fix: Pin exact versions. <code>FROM node:22.17.0-slim</code>. Lock it in your CI. Update deliberately, not accidentally.
<h2>Mistake 3: Bloated images with build dependencies</h2>
Your production image doesn’t need gcc, make, python, or your test framework. But single-stage Dockerfiles ship all of this to production, creating 2GB+ images that take forever to pull and contain unnecessary attack surface.
The fix — multi-stage builds:
<pre><code class="language-dockerfile"># Build stage
FROM node:22 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:22-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER appuser
CMD [&quot;node&quot;, &quot;dist/server.js&quot;]
</code></pre>
Your production image should contain only what’s needed to run. Nothing more.
<h2>Mistake 4: No health checks</h2>
Without a HEALTHCHECK instruction, Docker and your orchestrator have no way to know if your app is actually working. The container could be running but the process inside is deadlocked, out of memory, or stuck in an infinite loop.
The fix:
<pre><code class="language-dockerfile">HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
 CMD curl -f http://localhost:3000/health || exit 1
</code></pre>
This gives your orchestrator real information to make restart decisions, not just “is the PID alive.”
<h2>Mistake 5: Ignoring .dockerignore</h2>
No <code>.dockerignore</code> means Docker copies your entire directory into the build context — including <code>node_modules</code>, <code>.git</code>, <code>.env</code> files with secrets, test fixtures, and everything else. This slows builds, bloats images, and can leak sensitive data.
The fix:
<pre><code># .dockerignore
node_modules
.git
.env
*.log
test/
coverage/
.DS_Store
</code></pre>
Think of <code>.dockerignore</code> as your <code>.gitignore</code> for containers. If you don’t need it at runtime, exclude it.
<h2>Bonus: Stop using docker-compose in production</h2>
Docker Compose is for local development. If you’re running <code>docker-compose up -d</code> on a production server and calling it deployment, you’re one crashed server away from losing everything. Use proper orchestration — even a simple systemd unit file is better than hoping someone remembers to restart compose after a reboot.
Containers aren’t complicated. But the defaults are wrong for production, and the documentation buries the important stuff under tutorials about building a todo app. Get these 5 things right and you’ll avoid 90% of container incidents.
What Docker mistake cost your team the most time? Share your war stories below.

sirajju

Five persistent Docker mistakes still found in production environments in 2026: running containers as root (fix: add a non-root user in Dockerfile), using 'latest' image tags (fix: pin exact versions), bloated single-stage images with build dependencies (fix: multi-stage builds), missing health checks (fix: add HEALTHCHECK instruction), and ignoring .dockerignore (fix: exclude node_modules, .git, .env, etc.). A bonus warning advises against using docker-compose in production, recommending proper orchestration instead. Each mistake includes a concrete Dockerfile snippet or config example.

Docker in 2026: The 5 Mistakes Still Killing Your Containers in Production

The “running as root” one still shocks me in 2026. I recently audited a fintech startup with 50+ containers — every single one was running as root. Two lines of Dockerfile config could have saved them from a critical security finding.