30 Claude Prompts for Docker

You are a full stack engineer setting up local development environments. <context> I am starting a new project with a web app and a database and I want a docker compose file so any teammate can run everything with one command. </context> <inputs> - App image or build context: [APP IMAGE OR BUILD PATH] - Database engine and version: [DATABASE ENGINE AND VERSION] - App port mapped to host: [HOST PORT]:[CONTAINER PORT] - Environment variables the app needs: [LIST OF ENV VAR NAMES] - Whether data must persist across restarts: [YES OR NO] </inputs> <task> Write a docker compose file with an app service and a database service, wired together on a shared network with the app depending on the database being ready. </task> <constraints> Use a named volume for the database if persistence is required. Do not hardcode secrets, reference an env file instead. Use the current compose file syntax without the obsolete version key. </constraints> <format> A fenced yaml code block with the compose file, plus one line noting which command starts it. </format>

You are a developer experience engineer who owns local onboarding. <context> Our team's local setup instructions are a wall of manual steps and new hires lose half a day getting the stack running. </context> <inputs> - Services involved: [LIST OF SERVICES, e.g. API, WORKER, REDIS, POSTGRES] - Ports each service currently uses: [LIST OF PORTS] - Any service that needs hot reload for local editing: [SERVICE NAME OR NONE] - Existing setup doc if any: [PASTE CURRENT SETUP STEPS OR NONE] </inputs> <task> Design a docker compose file that replaces the manual setup steps, including a bind mount for the hot reload service so code edits show up without a rebuild. </task> <constraints> Keep service names short and consistent with the list given. Call out any port that is likely to conflict with a common local tool, like a default Postgres or Redis port already running on the host. Do not invent services that were not listed. </constraints> <format> Fenced yaml compose file, followed by a short "Before you run this" checklist of three items. </format>

You are a reliability engineer hardening a compose stack before it goes on a staging server. <context> Our compose stack works fine on laptops but on the staging server a service occasionally starts before its dependency is ready and crashes. </context> <inputs> - Current compose file: [PASTE COMPOSE FILE] - Service that fails on startup: [SERVICE NAME] - Service it depends on: [DEPENDENCY SERVICE NAME] - How the dependency signals readiness: [HTTP ENDPOINT OR PORT OR LOG LINE] </inputs> <task> Add a healthcheck to the dependency service and update the dependent service to wait for it to be healthy, not just started. Also add a sensible restart policy for a staging environment. </task> <constraints> Use condition service_healthy in depends_on, not a sleep command or a wait script, unless no readiness signal exists. Keep healthcheck intervals reasonable for staging, not so aggressive they add load. </constraints> <format> Return the modified compose sections only, in a fenced yaml block, with a one line comment above each new key explaining its purpose. </format>

You are a configuration management specialist reviewing environment setup. <context> Our compose file has environment variables scattered across the yaml file, an env file, and shell exports, and nobody is sure which one wins anymore. </context> <inputs> - Compose file environment sections: [PASTE ENVIRONMENT BLOCKS] - Contents of the env file if used: [PASTE .ENV CONTENTS OR NONE] - Variables that differ between local and staging: [LIST OF VARIABLE NAMES] </inputs> <task> Propose a single clear structure for environment variables using env files per environment, explain Docker Compose's precedence order for these sources, and rewrite the compose file to use it consistently. </task> <constraints> Explain precedence in plain sentences, not a link to documentation. Flag any variable that looks like a secret and recommend it be excluded from any file that gets committed. Keep the explanation under 200 words. </constraints> <format> A short "How precedence works here" section, then the cleaned up compose environment block in a fenced yaml code block, then a bullet list of variables flagged as secrets. </format>

You are an infrastructure engineer who explains networking to engineers new to Docker. <context> A new engineer on my team is confused about how our services reach each other inside the compose stack and keeps trying to use localhost between containers. </context> <inputs> - Compose file: [PASTE COMPOSE FILE] - Specific connection that is failing: [SOURCE SERVICE] to [TARGET SERVICE] - Error message seen: [PASTE ERROR MESSAGE] </inputs> <task> Explain, for someone new to Docker networking, why the connection is failing and what hostname or port it should use instead. Then produce a simple text diagram of how the services in this compose file can reach each other. </task> <constraints> Avoid jargon like "the default bridge network" without defining it once in plain terms. Keep the explanation to under 180 words before the diagram. The diagram must be plain text, not an image. </constraints> <format> A short explanation paragraph, then a text based diagram using arrows and service names inside a fenced code block. </format>

You are a build engineer specializing in converting single stage Dockerfiles into multi stage ones. <context> Our Dockerfile installs build tools and compilers that end up shipped in the final production image, and I want them stripped out. </context> <inputs> - Current single stage Dockerfile: [PASTE FULL DOCKERFILE] - Language or framework: [LANGUAGE OR FRAMEWORK] - Build tools currently installed that are not needed at runtime: [LIST OF BUILD TOOLS, e.g. GCC, MAKE] - Final artifact path after the build completes: [PATH/TO/BUILD/OUTPUT] </inputs> <task> Convert this into a multi stage Dockerfile with a build stage that includes the compilers and a runtime stage that only copies the compiled output. </task> <constraints> Name the stages clearly, for example "builder" and "runtime". Only copy the exact artifacts the runtime stage needs, not the whole build directory. List the exact size difference you expect in one sentence, phrased as an estimate. </constraints> <format> Fenced code block with the new multi stage Dockerfile, then one sentence estimating the size reduction. </format>

You are a security focused build engineer evaluating distroless images. <context> Security flagged that our runtime images contain a shell and package manager that attackers could use if a container is compromised, and asked us to look at distroless. </context> <inputs> - Current base image: [CURRENT BASE IMAGE AND TAG] - Language runtime: [LANGUAGE AND VERSION] - Things the app currently relies on at runtime, like shell scripts or curl: [LIST OF RUNTIME DEPENDENCIES] </inputs> <task> Assess whether a distroless base image is realistic for this app, list what would break, and provide a migration plan with the specific distroless image tag to use. </task> <constraints> Be honest if distroless is a bad fit, do not force a recommendation that ignores the listed runtime dependencies. If shell access is needed for debugging, suggest a debug variant tag as a documented alternative. </constraints> <format> A short verdict sentence, a bullet list of what breaks and how to fix each, then the recommended Dockerfile FROM line. </format>

You are a build engineer auditing why an image is larger than it should be. <context> Our final image is much bigger than similar services on the team and I have not been able to find the exact cause by eyeballing the Dockerfile. </context> <inputs> - Dockerfile: [PASTE FULL DOCKERFILE] - Output of docker history for the image: [PASTE DOCKER HISTORY OUTPUT] - Expected size based on similar services: [EXPECTED SIZE IN MB] </inputs> <task> Analyze the docker history output layer by layer, identify which layers contribute the most size, and explain the likely cause for each, such as unpinned dependency versions, cached package manager files, or copied test fixtures. </task> <constraints> Rank findings by size contribution, largest first. For each finding give the specific Dockerfile line to change. Do not guess if a layer size is ambiguous, say so instead of inventing a cause. </constraints> <format> A ranked list of findings, each with the layer size, the likely cause, and the fix, followed by a revised relevant Dockerfile snippet. </format>

You are a build engineer evaluating a switch to an alpine base image. <context> I want to shrink our image by switching to alpine but I have been burned before by musl versus glibc issues and want a real assessment first. </context> <inputs> - Language and version: [LANGUAGE AND VERSION] - Native or compiled dependencies in use: [LIST OF NATIVE PACKAGES] - Current base image: [CURRENT BASE IMAGE] </inputs> <task> Check each listed native dependency for known alpine or musl compatibility issues, and give a clear go or no go recommendation with the reasoning for each dependency. </task> <constraints> Be specific about which packages have known musl problems versus which are safe. If uncertain about a specific package, say so plainly instead of guessing. Do not recommend alpine just because it is smaller if compatibility risk is real. </constraints> <format> A table with columns dependency, risk level, and reasoning, followed by a one sentence final recommendation. </format>

You are a build engineer writing a report for a team retro on image slimming work. <context> I spent a sprint reducing our Docker image size and need to summarize the before and after for a team retro without it reading like a sales pitch. </context> <inputs> - Original image size: [ORIGINAL SIZE IN MB] - New image size: [NEW SIZE IN MB] - Changes made: [LIST OF CHANGES, e.g. MULTI STAGE BUILD, ALPINE BASE, REMOVED DEV DEPENDENCIES] - Build time before and after: [BEFORE MINUTES] to [AFTER MINUTES] </inputs> <task> Write a short factual summary of the size and build time improvement, attributing the reduction to each specific change where possible. </task> <constraints> Use plain numbers and percentages, no hype language. If the exact contribution of each change cannot be separated, say the total was not broken down by change rather than inventing a split. </constraints> <format> A short paragraph plus a two column table listing each change and its approximate impact. </format>

You are a build engineer who triages failed Docker builds for a living. <context> A docker build that worked yesterday is failing today and the log is long and confusing to me. </context> <inputs> - Full build log or the last 40 lines: [PASTE BUILD LOG] - Dockerfile: [PASTE FULL DOCKERFILE] - What changed since the last successful build, if known: [LIST OF RECENT CHANGES OR UNKNOWN] </inputs> <task> Identify the exact line in the Dockerfile that is failing, explain the root cause in plain terms, and give the fix. </task> <constraints> Quote the specific error line from the log, do not summarize it away. If the log suggests more than one possible cause, list them ranked by likelihood instead of picking one arbitrarily. </constraints> <format> A short "Root cause" section quoting the key log line, then a "Fix" section with the corrected Dockerfile snippet. </format>

You are a build performance engineer diagnosing slow CI builds. <context> Our Docker build takes far longer in CI than it does on my laptop and it is slowing down every pull request. </context> <inputs> - Dockerfile: [PASTE FULL DOCKERFILE] - Local build time: [LOCAL BUILD TIME IN MINUTES] - CI build time: [CI BUILD TIME IN MINUTES] - CI provider: [CI PROVIDER NAME] - Whether CI uses layer caching between runs: [YES OR NO OR UNKNOWN] </inputs> <task> List the most likely reasons a build is slower in CI than locally, evaluate each against the details given, and recommend concrete changes such as enabling registry cache or reordering instructions. </task> <constraints> Do not recommend a caching strategy without checking whether the CI provider supports it, based on what was stated. If cache status is unknown, make finding that out the first recommended step. </constraints> <format> A ranked list of causes with a likelihood label of high, medium, or low, each followed by one concrete action. </format>

You are a build engineer investigating unexpected cache misses. <context> Docker keeps rebuilding a layer I expect to be cached and I cannot figure out which instruction is breaking the cache. </context> <inputs> - Dockerfile: [PASTE FULL DOCKERFILE] - Layer that unexpectedly rebuilds: [DESCRIBE THE LAYER OR RUN COMMAND] - Build command used: [PASTE EXACT BUILD COMMAND] - Whether BuildKit is enabled: [YES OR NO OR UNKNOWN] </inputs> <task> Explain the exact reason this layer is invalidating cache, considering file checksums, ARG values, and build context changes, then give the smallest possible fix. </task> <constraints> Check for common causes in this order: changed files copied before this line, an ARG or ENV value that changes between builds, and .dockerignore gaps. State which one applies here specifically, not all three generically. </constraints> <format> A one paragraph diagnosis naming the specific cause, then the corrected Dockerfile lines in a fenced code block. </format>

You are an on call engineer investigating a container that keeps restarting. <context> A container is stuck in a crash loop right after I deployed a change and I need to find the cause quickly before this affects users. </context> <inputs> - Container logs from the last crash: [PASTE CONTAINER LOGS] - Exit code reported: [EXIT CODE] - What changed in this deploy: [DESCRIBE THE CHANGE] - Resource limits set on the container, if any: [MEMORY LIMIT AND CPU LIMIT OR NONE] </inputs> <task> Interpret the exit code and log content together, identify the most likely cause of the crash loop, and give the immediate mitigation step plus the real fix. </task> <constraints> Distinguish between an application error, a missing environment variable, and an out of memory kill, since the exit code alone can point to more than one. State your confidence level in the diagnosis. </constraints> <format> A "Likely cause" section with a confidence level, an "Immediate mitigation" section, and a "Real fix" section, each two sentences or fewer. </format>

You are a build engineer who reviews Dockerfiles the way a senior engineer reviews a pull request. <context> I want a second set of eyes on a Dockerfile before it merges, similar to running a linter but with reasoning attached. </context> <inputs> - Dockerfile to review: [PASTE FULL DOCKERFILE] - Where this image will run: [KUBERNETES OR ECS OR BARE DOCKER OR LOCAL ONLY] - Any known constraints, like a required base image: [LIST CONSTRAINTS OR NONE] </inputs> <task> Review the Dockerfile line by line and flag anything that would fail a code review, such as running as root, using latest tags, missing a healthcheck, or copying unnecessary files. </task> <constraints> Separate findings into must fix and nice to have. Do not flag something as a problem if the stated deployment target makes it a non issue, for example a healthcheck may be redundant if Kubernetes probes already exist. </constraints> <format> Two sections, "Must fix" and "Nice to have", each a bullet list referencing the specific line. </format>

You are a container security engineer hardening images against privilege escalation. <context> Our containers currently run as root inside the container, which a security review flagged as a risk if a container is ever compromised. </context> <inputs> - Dockerfile: [PASTE FULL DOCKERFILE] - Files or directories the app writes to at runtime: [LIST OF WRITE PATHS] - Port the app binds to: [PORT NUMBER] </inputs> <task> Modify the Dockerfile to create and switch to a non root user, and adjust file ownership and permissions so the app still works, including any low port binding issue. </task> <constraints> If the port number is below 1024, explain the specific complication with binding as a non root user and provide the actual fix, do not just say it is a known issue. Set ownership only on the paths that need it, not the whole filesystem. </constraints> <format> The modified Dockerfile in a fenced code block, followed by a short note on any low port complication if relevant. </format>

You are an application security reviewer focused on how secrets flow into containers. <context> I am worried our Dockerfile or compose file might be leaking secrets into image layers or logs and want a clear review before this ships. </context> <inputs> - Dockerfile: [PASTE FULL DOCKERFILE] - Compose file if used: [PASTE COMPOSE FILE OR NONE] - How secrets are currently passed in: [BUILD ARG OR ENV FILE OR RUNTIME ENV VAR] </inputs> <task> Identify any place a secret could end up baked into an image layer, exposed in build history, or logged in plain text, and recommend the correct mechanism, such as BuildKit secret mounts or runtime injected env vars. </task> <constraints> Be specific about the difference between a build time secret and a runtime secret, since they need different handling. Flag any ARG used for a secret value explicitly, since ARG values are visible in image history. </constraints> <format> A bullet list of findings, each labeled with severity high, medium, or low, followed by the corrected Dockerfile or compose snippet for the highest severity finding. </format>

You are a security engineer who triages container vulnerability scan results for engineering teams. <context> Our vulnerability scanner returned a long list of CVEs for our base image and the team does not know which ones actually matter for us. </context> <inputs> - Scan output, list of CVEs with severity: [PASTE SCAN RESULTS] - Base image and tag: [BASE IMAGE AND TAG] - Whether the app exposes the affected component to untrusted input: [YES OR NO OR UNKNOWN PER CVE] </inputs> <task> Group the CVEs into ones that are actually exploitable given how this app uses the image, ones fixed simply by bumping the base image tag, and ones that are noise for this specific service. </task> <constraints> Do not tell the team to just patch everything, prioritize by real exploitability given the stated exposure. If exposure is unknown for a CVE, put it in a separate "needs input" group rather than guessing. </constraints> <format> Three headed sections: "Fix now", "Fix on next update", and "Needs more input", each a short bullet list with the CVE id and one line of reasoning. </format>

You are a security engineer building a reusable security checklist for Dockerfiles. <context> We are about to onboard several new services and I want one checklist the whole team applies before any Dockerfile merges, instead of relying on memory. </context> <inputs> - Types of services this applies to: [LIST OF SERVICE TYPES, e.g. WEB API, WORKER, CRON JOB] - Deployment platform: [KUBERNETES OR ECS OR BARE DOCKER] - Compliance requirements if any: [SOC 2 OR HIPAA OR NONE] - Team size that will use this checklist: [TEAM SIZE] </inputs> <task> Produce a Dockerfile security checklist covering base image choice, user privileges, secret handling, and unnecessary packages, tailored to the stated platform and compliance context. </task> <constraints> Each checklist item must be something that can be verified by looking at a Dockerfile, not a vague principle. If a compliance requirement is named, tie at least two items directly to it. </constraints> <format> A numbered checklist, 10 to 15 items, each phrased as a yes or no check. </format>

You are a supply chain security engineer explaining image signing to an engineering team. <context> Our security team wants us to start signing container images and generating provenance data, and the engineers on my team do not understand why or what it involves. </context> <inputs> - CI provider: [CI PROVIDER NAME] - Registry used: [REGISTRY NAME, e.g. DOCKER HUB, ECR, GHCR] - Current level of familiarity on the team: [BEGINNER OR SOME EXPERIENCE] - Number of services that need signing set up: [SERVICE COUNT] </inputs> <task> Explain in plain terms what image signing and provenance actually protect against, then give the concrete steps to add signing to the CI pipeline for the stated provider and registry. </task> <constraints> Avoid abstract supply chain security language, ground the explanation in a concrete attack scenario it prevents. Name the actual tool to use, such as cosign or the registry's native signing feature, not a generic description. </constraints> <format> A short "Why this matters" paragraph with a concrete scenario, followed by a numbered setup steps list for the named CI provider and registry. </format>

You are a CI/CD engineer setting up automated Docker builds. <context> I need to add a Docker build and push step to our CI pipeline and want it done right the first time, including caching and tagging. </context> <inputs> - CI provider: [CI PROVIDER NAME] - Registry to push to: [REGISTRY NAME AND PATH] - Tagging scheme wanted: [GIT SHA OR SEMVER OR BOTH] - Whether this should run on every push or only on merge to main: [EVERY PUSH OR MERGE TO MAIN ONLY] </inputs> <task> Write the CI pipeline configuration for building and pushing the Docker image with the specified tagging scheme and trigger condition, including registry authentication. </task> <constraints> Use the CI provider's native caching mechanism for Docker layers if one exists, name it specifically. Do not hardcode registry credentials, reference the CI provider's secret storage by name. </constraints> <format> A fenced code block with the complete CI configuration file in the correct format for the named provider. </format>

You are an infrastructure engineer managing container registry costs. <context> Our container registry has thousands of old image tags piling up and both storage cost and the list of tags are becoming unmanageable. </context> <inputs> - Registry used: [REGISTRY NAME, e.g. ECR, GHCR, DOCKER HUB] - Current tagging scheme: [DESCRIBE HOW IMAGES ARE TAGGED] - Number of tags to retain: [RETENTION COUNT OR TIME WINDOW] - Tags that must never be deleted: [LIST OF PROTECTED TAGS, e.g. LATEST, PROD] - Approximate number of tags currently stored: [TAG COUNT] </inputs> <task> Design a cleanup policy that keeps the specified retention window, protects the named tags, and removes everything else automatically, using the native lifecycle feature of the stated registry if one exists. </task> <constraints> Name the exact registry feature or tool to use, do not describe cleanup abstractly. Protect any tag currently deployed to production even if it falls outside the retention window, and say so explicitly in the policy. </constraints> <format> A short description of the policy logic, then the actual configuration in a fenced code block for the named registry. </format>

You are an SRE writing operational runbooks for container deploys. <context> We deploy new Docker images to production manually right now and I want a written runbook so anyone on call can do it safely, not just the person who usually does it. </context> <inputs> - Deployment platform: [KUBERNETES OR ECS OR DOCKER SWARM] - Current deploy command or process: [DESCRIBE CURRENT PROCESS] - Rollback method available: [DESCRIBE ROLLBACK MECHANISM] - Health check endpoint used to confirm a healthy deploy: [ENDPOINT PATH] </inputs> <task> Write a step by step runbook for deploying a new image version with a rolling update, including how to verify health after the update and exactly how to roll back if the health check fails. </task> <constraints> Each step must be an exact command or action, not a description of what to do. Include a clear go or no go decision point tied to the health check result before continuing to the next step. </constraints> <format> A numbered runbook with exact commands, and a clearly marked "Rollback" section at the end. </format>

You are an observability engineer setting up centralized logging for containers. <context> Right now debugging a production issue means SSHing into a host and running docker logs, and I want logs centralized before the next incident. </context> <inputs> - Deployment platform: [KUBERNETES OR ECS OR DOCKER SWARM OR BARE DOCKER] - Logging backend to send to: [ELASTICSEARCH OR DATADOG OR CLOUDWATCH OR LOKI] - Current logging driver or setup, if known: [CURRENT SETUP OR UNKNOWN] - Approximate log volume: [LOG VOLUME ESTIMATE] </inputs> <task> Recommend the correct log collection approach for this platform and backend, and provide the specific configuration needed, such as a Docker logging driver setting or a sidecar agent configuration. </task> <constraints> Account for the stated log volume when recommending a driver, since some drivers handle high volume poorly without buffering. Name the exact driver or agent, not a generic "use a log shipper" answer. </constraints> <format> A short recommendation paragraph naming the specific driver or agent, followed by the configuration in a fenced code block. </format>

You are a platform engineer closing the gap between local Docker setups and production. <context> We keep having bugs that only show up in production because our local Docker setup drifted from how the containers actually run in production. </context> <inputs> - Local setup description: [DESCRIBE LOCAL COMPOSE OR DOCKER SETUP] - Production platform: [KUBERNETES OR ECS OR OTHER] - Known differences already identified: [LIST KNOWN DIFFERENCES OR NONE] - Recent bug caused by drift, if any: [DESCRIBE THE BUG OR NONE] </inputs> <task> Compare the local setup against the production platform's actual behavior, such as resource limits, environment variable sources, and network topology, and produce a checklist of specific parity gaps to close. </task> <constraints> Prioritize gaps that could plausibly cause the type of bug described, if one was given, at the top of the list. Do not recommend chasing perfect parity if a gap is low risk, say so explicitly. </constraints> <format> A prioritized checklist with each item labeled high, medium, or low risk, and one line explaining the specific parity gap. </format>