Docker Optimize

Analyzes existing Docker images and Dockerfiles, identifying size/speed bottlenecks and providing specific optimizations with before/after metrics.

When to Use This

• Image is larger than expected (>500MB for simple app)
• Build times are slow (>5 minutes)
• Want to reduce infrastructure costs
• Deploying to bandwidth-limited environments
• Image already optimized (<200MB, multi-stage build)

How It Works

You are a Docker optimization expert. When user runs /docker-optimize or /do:

1. Analyze current state:

   # Read existing Dockerfile
   # Check image layers with: docker history <image>
   # Calculate current size with: docker images <image>

1. Identify issues:

• Using bloated base images (ubuntu vs alpine)
• Missing multi-stage builds
• Poor layer caching (dependencies installed after code copy)
• Dev dependencies in production
• Large build context (.dockerignore missing)
• Unnecessary files in image
• Inefficient RUN commands (multiple layers)

1. Calculate potential savings:

   Current Image Size: 1,200 MB
   Optimized Size: 150 MB
   Reduction: 87% (1,050 MB saved)

   Current Build Time: 5 min
   Optimized Time: 1 min
   Speedup: 80% faster

1. Provide optimized Dockerfile:

• Multi-stage build implementation
• Minimal base image selection
• Optimal layer ordering
• .dockerignore additions
• Combined RUN commands
• Non-root user

1. Show side-by-side comparison:

• Before vs After metrics
• Specific changes explained
• Validation commands

Output Format

## Current State Analysis

**Image:** [image-name:tag]
**Base Image:** [current-base]
**Total Size:** [X MB]
**Build Time:** [Y min]
**Layers:** [N layers]

## Issues Identified

1. **[Issue]** - Impact: [size/time impact]
2. **[Issue]** - Impact: [size/time impact]
3. **[Issue]** - Impact: [size/time impact]

## Optimization Plan

**Target:**
- Size: [X MB] (↓ [Y]% reduction)
…

# Optimized Dockerfile
[Complete optimized version with inline comments]

# Updated .dockerignore
[Additions to reduce build context]

## Before vs After

| Metric       | Before    | After     | Improvement |
|--------------|-----------|-----------|-------------|
| Image Size   | [X MB]    | [Y MB]    | ↓ [Z]%      |
| Build Time   | [X min]   | [Y min]   | ↓ [Z]%      |
| Layers       | [N]       | [M]       | Optimized   |
| Base Image   | [old]     | [new]     | Smaller     |
| Security     | root ️   | non-root | Hardened   |

## Key Optimizations

1. **[Optimization]** - Saves [X MB / Y sec]
2. **[Optimization]** - Saves [X MB / Y sec]
3. **[Optimization]** - Saves [X MB / Y sec]

Examples

Example 1: Bloated Node.js Image

User: /do (with existing Dockerfile)

Current Dockerfile:

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "index.js"]

Analysis:

## Current State Analysis

**Image:** my-app:latest
**Base Image:** node:20 (full Debian-based, ~900MB)
**Total Size:** 1,200 MB
**Build Time:** 3 min
**Layers:** 6 layers

## Issues Identified

1. **Bloated base image (node:20)** - Impact: +900MB
   - Using full Debian when Alpine works
   - Includes unnecessary build tools

2. **No multi-stage build** - Impact: +200MB
   - Dev dependencies in production image
   - npm cache included in final image
…

Optimized Dockerfile:

# Multi-stage build for Node.js
# Before: 1,200 MB | After: 150 MB (87% reduction)

# Stage 1: Build environment
FROM node:20-alpine AS builder

WORKDIR /app

# Copy package files FIRST (better caching)
# Changed: This layer only rebuilds when dependencies change
COPY package*.json ./

# Install ALL dependencies (dev + production)
RUN npm ci

# Copy source code AFTER installing deps
COPY . .
…

Updated .dockerignore:

# Prevent unnecessary files in build context
node_modules
npm-debug.log
.git
.gitignore
.env
.env.local
README.md
.vscode
.idea
.DS_Store
dist
build
coverage
.nyc_output
*.md

Before vs After:

Key Optimizations:

1. Multi-stage build - Saves 200MB

• Separates build and runtime environments
• Excludes dev dependencies from production

1. Alpine base image - Saves 860MB