The prompt
Score 10 of 10, Excellent
Use it when You need to package an app as a container image for deployment and want a Dockerfile that builds quickly, stays small and does not run as root.
- {{reader}}
- {{platform}}
- {{stack}}
- {{build_and_run}}
- {{runtime_needs}}
- {{project_files}}
Full prompt and why it works
Prompt
Write a Dockerfile for the app below, for {{reader}} to build and deploy to {{platform}}, so that the image is small, rebuilds quickly when only code changes, and runs safely in production. The app: - Language, framework and versions: {{stack}} - How it is built and started today: {{build_and_run}} - Port, environment variables and files it needs at run time: {{runtime_needs}} Top-level files and the dependency manifest: """ {{project_files}} """ Requirements: 1. A multi-stage build where it helps: build tools and dev dependencies in the first stage, only what the app needs to run in the final one. 2. Base images from the official image for the language, pinned to a specific version tag rather than latest. Say which tag you chose and why; I will check that it is current. 3. Layers ordered for caching: copy the dependency manifest and install dependencies before copying the rest of the code. 4. Run as a non-root user, add a HEALTHCHECK if the app has a health endpoint, and write the start command in exec form. 5. A .dockerignore that keeps out .git, local environment files, build output and dependency folders. Output the Dockerfile in one code block and the .dockerignore in a second code block, with a comment on every line whose reason is not obvious, followed by the commands to build and run the image locally and a list of up to 5 points I should check. A good Dockerfile is one a teammate can read top to bottom and understand why each line is there. For example, the form of one comment: "# Install dependencies first so this layer stays cached when only source files change." Never copy secrets, .env files or credentials into the image or pass them as build arguments; they belong in the platform's secret settings at run time. Do not install packages the app does not need, such as editors or curl, unless the health check uses them. If the start command, the build output folder or a required system library is not clear from what I gave you, list it as a question and put a clearly marked placeholder in the Dockerfile instead of guessing.
Variables
- {{reader}}
- Who will build and maintain it, for example "me" or "our two-person backend team".
- {{platform}}
- Where it will run, for example Google Cloud Run, AWS ECS, Kubernetes or one server with Docker Compose.
- {{stack}}
- The language, framework and versions, for example "Node.js 22 with Next.js" or "Python 3.12 with Django".
- {{build_and_run}}
- The commands you use now, for example "npm ci, npm run build, then npm start".
- {{runtime_needs}}
- The port, the names of environment variables (not their values), and any files or folders the app reads or writes.
- {{project_files}}
- A listing of the project's top-level files and folders, plus the dependency manifest, such as package.json or requirements.txt. Remove any secrets first.
Why it works
- What to avoid. Secrets never go into the image or build arguments, and nothing is installed that the app does not need, the two problems container scans flag most often.
- What good looks like. Pinned base images, cache-friendly layer order and a non-root user are written as requirements, so the result is ready for production rather than a quick demo.
- If unsure. An unclear start command or build folder becomes a marked placeholder and a question, and the chosen base image tag is left for you to confirm is current.