AI Prompts for Docker and Containers

The Problem James Faced

Picture this: you're a full-stack developer at a mid-size SaaS company. The company just decided to containerize its five-year-old Node.js monolith. You've been handed the project because you "know Docker" — which means you've built a couple of hobby project containers and once deployed something to Docker Swarm.

The first Dockerfile you wrote with AI assistance worked. Your container ran locally. You pushed it to the container registry and deployed to the staging environment. The container was 2.1 GB.

Your DevOps lead saw the image size and sent you a single Slack message: "We need to talk."

James had asked for a "Dockerfile for a Node.js application." The AI gave him a perfectly functional Dockerfile. It also included: all dev dependencies, the Node.js build tools that weren't needed at runtime, the complete git history in the build context, and no .dockerignore file to exclude any of it.

The Wrong Approach

Write a Dockerfile for a Node.js application.

The app uses:
- Node.js 20
- Express
- PostgreSQL via pg
- TypeScript (compiled to JavaScript before running)

The AI wrote a single-stage Dockerfile. It copied everything, ran

npm install

npm run build

The production service had three problems:

• Size: 2.1 GB images take significantly longer to pull during deploys
• Security surface: dev dependencies and build tools increase the attack surface
• Build context: without .dockerignore, the entire project directory (including node_modules from local dev) was sent to the Docker daemon on every build

⚠️ Common mistake: Writing Dockerfiles without specifying multi-stage builds for compiled languages and frameworks. Any project that has a "build" step (TypeScript compilation, Go compilation, webpack bundle) should use multi-stage builds to separate build tools from the runtime image.

The Correct Prompt

You are a Docker expert. Write a production-optimized Dockerfile for a Node.js TypeScript application.

Application details:
- Node.js 20 LTS
- TypeScript (src/ compiled to dist/)
- Dependencies: Express, pg, other runtime packages in package.json
- Dev dependencies: TypeScript, ts-node, ESLint, Jest — these should NOT be in the final image

Optimization requirements:
1. Multi-stage build: stage 1 (builder) installs all dependencies and compiles TypeScript; stage 2 (production) copies only compiled output and production dependencies
2. Base image: use node:20-alpine for the production stage (not node:20 or node:latest)
3. Layer caching: copy package.json and package-lock.json BEFORE copying source code, so npm install is cached when only source changes
4. Run as non-root: add a non-root user for the production stage
5. Production dependencies only: npm ci --only=production in the final stage

Also provide:
- A .dockerignore file that excludes: node_modules, .git, dist, *.md, .env files
- A docker-compose.yml for local development with hot-reload
- The expected image size after these optimizations (estimate)

What this does: Specifies every optimization dimension explicitly — multi-stage, Alpine base, layer ordering, non-root user, production-only deps — so the AI can't default to a simple single-stage build.

⚡ Pro tip: Add "calculate the approximate layer size for each COPY and RUN instruction" to any Dockerfile prompt. Understanding which layers are large helps you identify where further optimization is possible — and explains why layer order matters for caching.

Results and What Changed

The optimized Dockerfile reduced the image from 2.1 GB to 187 MB — an 11× size reduction. Deploy time to staging dropped from 4 minutes to 45 seconds.

Beyond size, three production wins:

Security posture: No TypeScript compiler or ESLint in the production image means a smaller attack surface. If someone gains code execution in the container, they have fewer tools to work with.

Faster CI: Smaller images pull faster from the registry, which cut 3+ minutes from every pipeline run.

Layer caching: The correct layer order means that rebuilding after a source change (without dependency changes) reuses the expensive

npm install

James's DevOps lead sent a follow-up Slack message: "That's more like it."

How to Apply This to Your Situation

The multi-stage + Alpine + layer-order framework applies across languages:

For Python applications:

Write a multi-stage Dockerfile for a Python 3.11 FastAPI application. Stage 1: install build dependencies and compile requirements. Stage 2: copy virtual environment and application code to a python:3.11-slim base. Non-root user in production stage. .dockerignore excluding: __pycache__, .venv, .git, *.pyc, tests/.

What this does: Python images bloat significantly with build tools. Slim base + virtual environment copy reduces image size by 60–70% versus a naive single-stage build.

For Go applications:

Write a multi-stage Dockerfile for a Go application. Stage 1 (builder): golang:1.22 base, compile with CGO_ENABLED=0 GOOS=linux for a static binary. Stage 2 (production): scratch or distroless/static base — just the binary, no OS. The final image should be under 20 MB.

What this does: Go compiles to a static binary, which means the production image can be just the binary with no OS at all — the smallest possible attack surface.

⚡ Pro tip: For containers that need secrets at runtime (database credentials, API keys), prompt for: "Show how to inject secrets as environment variables via Docker secrets or at runtime — never bake secrets into the image layer." Secrets in image layers persist in the registry and are visible to anyone who can pull the image.

Next Steps

Container optimization is one of those areas where a 20-minute prompt session produces measurable production improvements that every deploy benefits from. The size reduction, caching improvements, and security hardening persist indefinitely.

Save your language-specific Dockerfile templates in PromptABCD. Your ai prompts docker containers toolkit — Node.js, Python, Go, with their respective optimizations — means every new service starts with a production-ready container, not a 2 GB demo.

Container Security Hardening

Container security goes beyond image size. A container that's small but runs as root with unrestricted capabilities is still a security risk. A targeted hardening prompt:

Review this Dockerfile for security hardening opportunities. Check:
1. Process user: does the container run as non-root? If not, add a non-root user
2. Read-only filesystem: can the filesystem be mounted read-only? Add --read-only in the run command if possible
3. Capability dropping: the container likely doesn't need all Linux capabilities — suggest which to drop
4. Health check: is there a HEALTHCHECK instruction so the orchestrator knows when the container is unhealthy?
5. Environment variables: any secrets set as ENV instructions (these are visible in docker inspect)
6. Image vulnerabilities: the base image chosen — when was it last updated? Is there a more recent version?

Dockerfile: [paste]

What this does: Security hardening is a different concern than optimization — this prompt specifically addresses the runtime security posture rather than build efficiency.

⚡ Pro tip: For containers that need to write temporary files, ask: "Rather than making the entire filesystem writable, identify the specific directories this application writes to at runtime and add only those as volumes." Minimal writeable surface means minimal attack impact if the container is compromised.

Docker Compose for Development

Docker Compose for local development is a separate prompt domain from production Dockerfiles. The goals differ: local dev prioritizes fast iteration (hot-reload, easy debugging) over security and size.

Write a docker-compose.yml for local development of this application. Requirements:
- Hot-reload: source code mounted as a volume, not copied into the image — changes reflect without rebuild
- Development database: include a PostgreSQL service with a named volume for data persistence across container restarts
- Environment variables from .env file (include a .env.example with descriptions, never commit .env)
- Port mappings that avoid conflicts with common local services
- Health checks so dependent services wait for dependencies to be ready (not just started)
- A separate docker-compose.override.yml for developer-specific customizations (not committed to git)

Application: [describe your service and its dependencies]

What this does: The "hot-reload via volume mount" is the key development experience improvement that naive docker-compose configs miss. The docker-compose.override.yml pattern is the underused feature that prevents the "I always need to change this one thing" hack that breaks everyone else's local setup.

Container Registry Management

After building optimized images, how you manage them in the registry matters:

Write a CI/CD stage that manages container image lifecycle in [ECR / DockerHub / GCR]. Include: tagging with git SHA, branch name, and 'latest' (for the main branch only), a retention policy that keeps the last 10 images per branch and all release-tagged images, and image vulnerability scanning before pushing to production registry. Note: never push an image with High or Critical vulnerabilities to the production registry.

What this does: Registry management is the often-forgotten phase between building an image and running it. Without a retention policy, registries accumulate gigabytes of unused images. Without vulnerability scanning at push time, vulnerable images silently enter the production registry.

⚡ Pro tip: Ask the AI to generate a Docker container health check for your specific application: 'Write a HEALTHCHECK instruction for this [Node.js/Python/Go] container. The health check should test actual application functionality (not just that the process is running) — for an HTTP service, it should make a real HTTP request to a lightweight health endpoint and check the response code and latency.' A proper health check is what allows Kubernetes and Docker Compose to detect a container that's running but not actually serving traffic.

Your full Docker toolkit — production Dockerfile, development Compose, security hardening, registry management — saved in PromptABCD gives you complete coverage of the container lifecycle. Every new service starts from your best practices, not from square one.