Docker prompts for ChatGPT, Claude and Codex

The best Docker prompts give the model your app's language, how it starts and the real output from Docker, then ask for a Dockerfile or fix you can build and run right away. Below are 12 Docker prompts for ChatGPT, Claude, Claude Code and Codex for writing Dockerfiles, shrinking images, speeding up builds, handling secrets, writing Compose files and debugging containers.

If you want an agent to follow Dockerfile rules automatically instead of pasting prompts, see the Docker skill guide, which covers a multi-stage Dockerfile skill for Claude Code.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{language:Node.js}} means Node.js unless you change it.

Three habits give much better results:

• Paste real Docker output. docker history, docker logs, docker inspect and build logs tell the model what actually happened.
• Describe the target. Production or local development, the platform it deploys to, and whether the image is public.
• Build and run every answer. A Dockerfile that looks right can still fail on the first COPY. Docker's build checks (docker build --check .) catch common mistakes without running the build.

In an agent, let it run the commands and read the output directly.

How do you write a production Dockerfile with AI?

1. Write a production Dockerfile

The starting prompt for any service. Multi-stage builds keep compilers and dev dependencies out of the final image.

Write a production Dockerfile for a {{language:Node.js}} {{app_type:web API}}.

How it builds: {{build_command:npm run build}}
How it starts: {{start_command:node dist/server.js}}
Port: {{port:3000}}

Requirements:
- Multi-stage build: dependencies and build in one stage, a small runtime
  stage that copies only what it needs.
- Pin the base image to a specific version tag.
- Run as a non-root USER.
- Exec-form CMD so the app receives stop signals.
- Order layers so code changes don't reinstall dependencies.

Explain each stage in one line, then give a matching .dockerignore.

2. Write a .dockerignore

For slow builds that send gigabytes of context, or images that accidentally contain .env files.

Write a .dockerignore for a {{language:Node.js}} project with this layout:

{{tree}}

Exclude version control, local environment files, secrets, dependency
folders that get reinstalled in the image, test output, editor files and
build artifacts that the Dockerfile rebuilds. Comment each group. Flag
anything in the tree that looks like a secret.

3. Shrink a large image

For images that are hundreds of megabytes bigger than they should be. The layer sizes show where the weight is.

My image is {{size:1.4 GB}}. I want it under {{target:200 MB}}.

Dockerfile:
{{dockerfile}}

Output of `docker history --no-trunc {{image:myapp:latest}}`:
{{history}}

Rank the changes by size saved: smaller base image, a separate build
stage, removing package manager caches in the same layer, and dropping dev
dependencies. Show the rewritten Dockerfile and estimate the new size.
Note any change that could break the app, such as missing system libraries
on a slim or distroless base.

4. Speed up a slow build

For builds that reinstall everything after a one-line change. Docker's cache guide covers layer order, .dockerignore and cache mounts with RUN --mount=type=cache.

This Docker build takes {{duration:6 minutes}} even when I change one source
file. Build log:

{{build_log}}

Dockerfile:
{{dockerfile}}

Find why the cache is invalidated and fix it: layer order, copying
dependency manifests before source code, cache mounts for
{{package_manager:npm}}, and a tighter .dockerignore. Show the new
Dockerfile and which steps should now be cached on a code-only change.

5. Remove secrets from a build

For Dockerfiles that pass tokens through ARG or ENV. Docker's build secrets page says these "persist in the final image."

This Dockerfile uses a secret ({{secret:an npm token}}) during the build
through ARG or ENV. Rewrite it to use a BuildKit secret mount instead.

Give me:
- The changed RUN instruction with --mount=type=secret
- The docker build command with --secret
- The matching step for {{ci:GitHub Actions}}
- How to check the final image no longer contains the secret

{{dockerfile}}

How do you write Compose files with AI?

6. Write a Compose file for local development

For running the app with its database and cache in one command. Healthchecks plus depends_on with condition: service_healthy stop the app from starting before the database is ready, as the Compose services reference describes.

Write a compose.yaml for local development of a {{language:Node.js}} app
with {{services:PostgreSQL and Redis}}.

- Healthchecks for each backing service.
- The app waits for them with depends_on and condition: service_healthy.
- Named volumes so database data survives restarts.
- Source code mounted for live reload, without overwriting installed
  dependencies inside the container.
- Environment variables read from a .env file, with a .env.example.

Explain how to reset the database to empty.

7. Split development and production settings

For one Compose setup that has grown flags for every environment.

This compose.yaml mixes development and production settings. Split it into
a base file plus {{override:a development override}}, so production uses
built images with no source mounts or debug ports.

Show each file, the exact docker compose commands to run each environment,
and a list of settings that moved and why.

{{compose_file}}

How do you debug Docker containers with AI?

8. Container exits right after starting

For containers that show "Exited" a second after docker run.

My container exits immediately after starting.

Status line from `docker ps -a` (shows the exit code):
{{status}}

Output of `docker logs {{container:myapp}}`:
{{logs}}

Dockerfile CMD and ENTRYPOINT:
{{cmd}}

Explain what the exit code means, the most likely cause, and the fix. Give
me one command to start the container with a shell so I can look around.

9. Containers can't reach each other

For "connection refused" between services. The usual cause is using localhost inside a container.

My {{client:app}} container can't connect to {{server:the database}}.

Error: {{error}}
Connection string or URL the app uses: {{connection}}
compose.yaml or docker run commands:
{{config}}

Explain what localhost means inside a container, check service names,
networks, published ports versus container ports, and whether the server
listens on all interfaces. Give the fix and a command to test the
connection from inside the client container.

10. Container is slow to stop

For docker stop that waits before killing the app, which also means lost requests on deploy.

`docker stop` on my container waits and then kills the app instead of
stopping it cleanly.

Dockerfile:
{{dockerfile}}

How the app handles shutdown: {{shutdown:I don't know}}

Explain the PID 1 and signal problem, including shell-form versus
exec-form CMD and ENTRYPOINT. Fix the Dockerfile, and show the code to
handle SIGTERM in {{language:Node.js}}: stop taking new requests, finish
current ones, close connections, exit.

How do you secure Docker images with AI?

11. Review a Dockerfile for security

For a pass before an image goes to production or a public registry.

Review this Dockerfile for security. Check:
- Running as root
- Secrets in ARG, ENV, COPY or layers
- Unpinned or unofficial base images
- Packages that aren't needed at runtime
- Files copied that shouldn't be (.git, .env, keys)
- Writable paths and ports exposed

Rank findings by risk, show the fix for each, and say which ones matter
less for {{context:an internal service}}.

{{dockerfile}}

12. Triage image scan results

For a vulnerability scan with 200 findings and no time.

Here is the vulnerability scan for my image from {{scanner:Docker Scout}}:

{{scan_output}}

Dockerfile:
{{dockerfile}}

Group findings by where they come from: base image, OS packages or app
dependencies. For each group, give the single change that fixes the most
findings. Separate what is actually reachable in this app from what is
only present in the image. Do not invent CVE details that aren't in the
output.

What should you check before you ship the output?

Run each answer through a quick checklist before it reaches production:

If any check fails, paste the output back into the same conversation. The model fixes its own mistakes much faster with the real error in front of it.

Turn your favorite one into a skill

If you write Dockerfiles often, a skill beats a pasted prompt: Claude Code or Codex applies it whenever the task matches. The production Dockerfile and security review prompts make good skills. Paste one into the free SKILL.md generator, or start from an existing one in the Docker skill guide. Once your images run, the Kubernetes prompts pick up at deployment.

Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks like {{language:Node.js}} stay fillable, Cmd+K finds any prompt, and skills you save there install into Claude Code or Codex with one command.