9 Prompts for Docker: From Dockerfile to Multi-Stage Builds

Introduction

Docker has become the de facto standard for containerization, enabling developers to package applications with their dependencies into lightweight, portable containers. Whether you are writing a simple web service or orchestrating a microservices architecture, mastering Docker requires more than just running docker run. It demands a deep understanding of how to craft efficient Dockerfiles, compose multi-container setups, and optimize images for production.

In this article, we present nine battle-tested prompts that you can use with an AI assistant to accelerate your Docker workflow. Each prompt is accompanied by a real usage example and practical advice. These prompts cover Dockerfile creation, Compose configuration, image optimization, multi-stage builds, and troubleshooting. By the end, you will have a toolkit of ready-to-use commands and patterns that save time and reduce errors.

1. Generate a Dockerfile for a Node.js Application

Prompt: "Write a production-ready Dockerfile for a Node.js Express app. Use Alpine image, install only production dependencies, and expose port 3000. Add a healthcheck that pings /health every 30 seconds."

Example output:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
CMD ["node", "server.js"]

Why it works: This prompt produces a multi-stage Dockerfile that separates build and runtime stages, keeping the final image small. The Alpine base reduces vulnerabilities, and the healthcheck ensures container orchestrators can monitor the service.

2. Create a docker-compose.yml for a Full-Stack App

Prompt: "Generate a docker-compose.yml for a React frontend, Node.js backend, and PostgreSQL database. Include a volume for PostgreSQL data, environment variables, and a network so services can communicate by service name."

Example output:

version: '3.8'
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    depends_on:
      - backend
    networks:
      - app-network

  backend:
    build: ./backend
    ports:
      - "5000:5000"
    environment:
      - DB_HOST=db
      - DB_USER=user
      - DB_PASSWORD=pass
      - DB_NAME=myapp
    depends_on:
      - db
    networks:
      - app-network

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

volumes:
  pgdata:

Why it works: This prompt creates a complete local development environment with a custom network. Services resolve each other by name, and data persists in a named volume. The depends_on ensures proper startup order.

3. Optimize a Docker Image Size

Prompt: "I have a Dockerfile that produces a 1.2 GB image for a Python Flask app. List the top 5 ways to reduce its size. Provide commands for each."

Example output:

1. Use a slim base image: Replace FROM python:3.12 with FROM python:3.12-slim — saves ~800 MB.
2. Remove build dependencies: Use multi-stage builds — copy only the final artifacts.
3. Combine RUN commands: Merge apt-get update and apt-get install into one layer to avoid caching intermediate layers.
4. Clean package manager caches: Add && rm -rf /var/lib/apt/lists/* after installs.
5. Exclude unnecessary files: Use .dockerignore to skip __pycache__, .git, and venv.

Example optimized Dockerfile snippet:

FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY . .
CMD ["python", "app.py"]

Why it works: Each suggestion addresses a common source of bloat. The multi-stage approach alone can cut image size by 50–70%.

4. Write a Multi-Stage Build for a Go Binary

Prompt: "Create a multi-stage Dockerfile for a Go application. The first stage builds the binary, the second stage uses scratch image. Include CGO_ENABLED=0 for static linking."

Example output:

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server .

FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

Why it works: The scratch image contains nothing but the binary, resulting in an incredibly small image (often under 20 MB). Static linking avoids dependencies on C libraries.

5. Debug a Container That Exits Immediately

Prompt: "My Docker container exits with code 139 (segfault) right after start. How do I debug this? Provide steps using docker logs, docker run --entrypoint, and core dumps."

Example steps:

1. Check logs: docker logs <container_id>
2. Run with interactive shell: docker run --rm -it --entrypoint /bin/sh <image>
3. Enable core dumps: docker run --ulimit core=-1 --cap-add=SYS_PTRACE --security-opt seccomp=unconfined <image>
4. Use strace inside container: docker run --rm -it --entrypoint strace <image> -f -o /tmp/strace.log /app/server

Why it works: Exit code 139 often indicates a segmentation fault caused by memory corruption or missing dependencies. These commands give you visibility into the runtime environment.

6. Set Up a CI/CD Pipeline with Docker Compose

Prompt: "Write a GitHub Actions workflow that builds a Docker image, runs tests using docker-compose, and pushes the image to Docker Hub. Assume the repo contains a docker-compose.test.yml."

Example output:

name: Docker CI
on: [push]
jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and test with Docker Compose
        run: docker compose -f docker-compose.test.yml up --abort-on-container-exit --exit-code-from test
      - name: Build production image
        run: docker build -t ${{ secrets.DOCKER_USERNAME }}/myapp:latest .
      - name: Push to Docker Hub
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push ${{ secrets.DOCKER_USERNAME }}/myapp:latest

Why it works: This pattern ensures tests run in an environment identical to production. The --exit-code-from flag propagates the test container's exit code, so the pipeline fails on test failure.

7. Create a .dockerignore File

Prompt: "Generate a .dockerignore file for a Node.js project that excludes node_modules, .env, .git, build artifacts, and IDE config files."

Example output:

node_modules
.env
.git
build
dist
*.log
.idea
.vscode
*.md
.gitignore
Dockerfile
docker-compose*

Why it works: Every file in the build context is sent to the Docker daemon, even if not used. A good .dockerignore reduces build time and prevents secrets from leaking into the image.

8. Use Docker Secrets for Sensitive Data

Prompt: "How do I pass a database password to a Docker container without exposing it in the Dockerfile or env file? Show an example using Docker secrets with docker-compose."

Example output:

version: '3.8'
services:
  app:
    build: .
    secrets:
      - db_password
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Then in your application, read the file at /run/secrets/db_password instead of an environment variable.

Why it works: Docker secrets are stored in memory and never written to logs or environment variables. This is a built-in security feature for Swarm mode, but works with Compose file version 3.1+.

9. Troubleshoot Network Connectivity Between Containers

Prompt: "Two containers on the same network cannot reach each other. My frontend tries to connect to backend:5000 but gets connection refused. Provide a checklist of commands to diagnose."

Example checklist:

1. Verify they are on the same network: docker network inspect <network_name>
2. Check container IPs: docker inspect <container_id> | grep IPAddress
3. Test connectivity from inside: docker exec -it frontend_container ping backend_container
4. Verify the service is listening: docker exec backend_container netstat -tulpn | grep 5000
5. Check firewalls inside container: docker exec backend_container iptables -L
6. Restart the backend container: docker-compose restart backend

Why it works: These steps systematically rule out network configuration, service availability, and firewall issues. Most connection problems are due to mismatched network names or services not binding to the correct interface.

Conclusion

Docker’s power lies in its ability to create consistent, isolated environments, but achieving that consistency requires careful configuration. The nine prompts above address the most common tasks and pain points developers face daily — from writing efficient Dockerfiles to debugging runtime failures. By integrating these prompts into your workflow, you can reduce boilerplate, avoid security pitfalls, and build smaller, faster images.

Remember that the Docker ecosystem evolves rapidly. As of mid-2026, Docker Compose v2 is standard, and multi-stage builds are essential for production images. Use these prompts as a foundation, and adapt them to your specific stack. Happy containerizing!