🐳 Docker Image Optimization & Security¶

• Slow builds, huge images, security vulnerabilities, dependency bloat — all of these come from poorly designed images.

This blog covers:

• Multi-stage builds

• Slim base images

• Minimizing attack surface

• Non-root users

• Caching & build layers

• Reproducible builds

• Trivy vulnerability scanning

• Production-ready patterns

• Plus hands-on labs + interview questions.

1️⃣ Why Image Optimization Matters¶

A good Docker image is:

• small
• secure
• fast to build
• reproducible
• low attack surface
• easy to cache

Benefits:

• Faster CI/CD & deployments
• Lower storage costs
• Fewer vulnerabilities
• Faster scaling in Kubernetes/Swarm

Most teams ship 1–2GB bloated images.
But, You won’t.

2️⃣ Start With the Right Base Image¶

❌ Bad choice (beginner):¶

FROM node:latest  

Reasons:¶

• unpredictable

• huge

• includes useless packages

✔ Better choices¶

For development:¶

FROM node:18 
# Consistent & stable.  

For production:¶

FROM node:18-slim 
# Lightweight Debian base, safe for production.

For maximum optimization:¶

FROM node:18-alpine 

🔸 But Alpine is not always recommended for heavy builds (openssl issues, musl libc differences).

Use Alpine only when your dependencies support it.

3️⃣ Multi-Stage Builds (Must Know)¶

The best way to shrink images.

Example Node.js multi-stage Dockerfile:¶

##### Stage 1 — Build #####

FROM node:18-slim AS builder

WORKDIR /app  

COPY package*.json ./

RUN npm ci  

COPY . .

RUN npm run build



##### Stage 2 — Run #####

FROM node:18-slim

WORKDIR /app  

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

COPY --from=builder /app/node_modules ./node_modules  

USER node  

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

Benefits:

✔ No dev dependencies in final image

✔ No build tools included

✔ Final image is minimal

✔ Very secure

🔥 This should be your default for production.

4️⃣ Reduce Attack Surface¶

❌ Avoid installing unnecessary packages¶

Avoid doing:

RUN apt update && apt install curl nano wget vim python3 build-essential  

Only install what you absolutely need.

✔ Use "distroless" images (Google)¶

Examples:

gcr.io/distroless/nodejs18  

They contain:

• No shell

• No package manager

• No hacking tools

• No /bin/bash

This is the 🔐 most secure runtime possible.

5️⃣ Eliminate Dev Dependencies¶

For npm:

RUN npm ci --omit=dev

For yarn:

RUN yarn install --production

This cuts:

• dotenv

• nodemon

• jest

• eslint

• prettier

• debug tooling

Your production image should include only runtime dependencies.

6️⃣ Caching Optimization (Fast Builds)¶

Docker caches layers top-down.

Good structure:

COPY package*.json ./

RUN npm ci

COPY . .

Because:

• When code changes → only last layer rebuilds

• Dependencies (npm ci) stay cached

7️⃣ Avoid COPY . . in root stage¶

Why? ➡️ Because it breaks caching.

Better:

COPY package.json package-lock.json ./

RUN npm ci

COPY src ./src

COPY prisma ./prisma

COPY tsconfig.json .

Optimized caching ➡️ fast CI builds.

8️⃣ Do Not Run as Root (Security 101)¶

Containers run as root by default. Huge security risk.

Add:

RUN adduser --disabled-password appuser
USER appuser 

Or for Node:

USER node 

This prevents privilege escalation inside the container.

9️⃣ Pin Your Versions (Reproducible Builds)¶

Bad:

FROM node:latest
npm install express 

Good:

FROM node:18.18.0-slim
npm ci

Reproducible builds = stable production.

🔟 Use .dockerignore (Most Underestimated)¶

.dockerignore

node_modules

.git

.env

secrets/

tests/

coverage/

Benefits:

✔ faster builds

✔ smaller build context

✔ fewer cache busts

✔ prevents secret leaks

1️⃣1️⃣ Scan Your Images for Vulnerabilities (Trivy)¶

#### Every CI pipeline should include this step.

Install:

brew install trivy  

Scan an image:

trivy image myapp:latest 

Scan filesystem:

trivy fs .  

Scan Dockerfile:

trivy config .  

1️⃣2️⃣ Hands-On Labs¶

🧪 Lab A — Shrink Node.js Image Size by 500MB¶

Step 1: Build naive image¶

FROM node:18

WORKDIR /app

COPY . .

RUN npm install

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

Build:

docker build -t bad-app .

docker images  

Usually ~800–900MB.¶

Step 2: Build optimized image¶

Use multi-stage + slim:

FROM node:18-slim AS builder

WORKDIR /app  

COPY package*.json ./

RUN npm ci  

COPY . .

RUN npm run build



FROM node:18-slim

WORKDIR /app  

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

COPY --from=builder /app/node_modules ./node_modules  

USER node

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

Build again:

docker build -t good-app .

docker images  

You should see:

➡ bad-app: ~900MB

➡ good-app: ~120–150MB

This is a 6–8× reduction.

🧪 Lab B — Run App as Non-Root¶

Dockerfile:

RUN addgroup app && adduser -S -G app app

USER app  

Check inside container:

> whoami 
        # OUTPUTS
> app

🔐 Security Checklist for Production Images¶

• Use slim or distroless base images

• Use non-root user

• No dev dependencies

• Minimize installed packages

• Do not include .env or secrets

• Use multi-stage builds

• Pin exact versions

• Use .dockerignore

• Run Trivy scans in CI

• Keep images under 300MB

• Remove shells when possible (distroless)

• Use minimal base images (alpine, distroless)

• Avoid running as root

• Scan images regularly

• Keep Docker updated

• Use .dockerignore

17. .dockerignore Example¶

node_modules 

.git  

.env  

dist  

👨‍💼 Interview Questions (With Answers)¶

❓1. What is multi-stage build?¶

A Dockerfile technique to separate build env and runtime env reducing image size and increasing security.

❓2. Difference between slim, alpine, and distroless?¶

❓3. What is the benefit of running non-root containers?¶

Prevents privilege escalation and reduces severity of container breakout attacks.

❓4. How does Docker caching work?¶

Each Dockerfile instruction creates a layer.

If input changes, that layer and below are rebuilt.

❓5. How do you scan a Docker image?¶

Using Trivy:

trivy image myapp  

¶

❓6. Why use npm ci instead of npm install?¶

npm ci provides reproducible builds using lockfile.

🏁 Final Summary¶

You now understand the core principles of building fast, secure, production‑ready Docker images, including:

• ✔ Slim base images
• ✔ Multi‑stage builds
• ✔ Reducing attack surface
• ✔ Running containers as non‑root
• ✔ Effective Docker layer caching
• ✔ Reproducible builds with pinned versions
• ✔ Vulnerability scanning with Trivy
• ✔ Proven optimization patterns
• ✔ Hands‑on practical labs
• ✔ Interview‑ready concepts and answers