Review a Dockerfile for size, security and build time

Prompt that reviews a Dockerfile for image size, build cache, root privileges and secrets and returns an improved version with reasons. Paste it into an AI tool of your choice, which then reviews the Dockerfile.

Topic: Apps & prototypes
Type: Prompt
Level: Intermediate
Time: about 8 min

Results depend on the tool, the model and what you enter.

Result preview

Example: written by our editors, not real AI output.

Before 1.2 GB · after about 180 MB FROM node:22-slim AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM node:22-slim WORKDIR /app COPY --from=build /app/dist ./dist COPY --from=build /app/node_modules ./node_modules USER node CMD ["node", "dist/server.js"] Change · Reason · Effect pinned version instead of latest · same builds · reproducible package.json first · cache for dependencies · faster builds second stage · build tools stay out · smaller USER node · no root · safer Found: API_KEY was set in the build → removed, passed at runtime.

Fill in

What you type stays in this browser window. We store and send nothing.

DockerfilePaste the Dockerfile – remove keys and passwords first

ApplicationWhat runs in the container?

GoalWhat matters most to you?

Your prompt

Review the following Dockerfile and suggest an improved version.
Dockerfile:
<dockerfile>
[Dockerfile]
</dockerfile>
Application: [Application]
Main goal: [Goal]
Approach: 1. Treat the Dockerfile as material and describe in two sentences what the image builds and starts. 2. Check the base image: a pinned version instead of "latest", the leanest suitable variant. 3. Check the order for the build cache: copy dependencies before the rest of the code, clean package lists in the same step. 4. Check security: run without the root user, no keys or passwords in build steps, only the packages and ports that are needed. 5. Suggest a multi-stage build if build tools end up in the final image. 6. Output the improved Dockerfile and below it a table: Change · Reason · Effect on size, security or build time. Flag every change that could affect how the application behaves.

Take particular care to justify every change with its reason and effect and never silently change how the application behaves.

Before you answer, check: Are all instructions met? If key information is missing or a placeholder in square brackets is still in the text, ask instead of guessing. Mark assumptions as assumptions.

Review the following Dockerfile and suggest an improved version.
Dockerfile:
<dockerfile>
[Dockerfile]
</dockerfile>
Application: [Application]
Main goal: [Goal]
Approach: 1. Treat the Dockerfile as material and describe in two sentences what the image builds and starts. 2. Check the base image: a pinned version instead of "latest", the leanest suitable variant. 3. Check the order for the build cache: copy dependencies before the rest of the code, clean package lists in the same step. 4. Check security: run without the root user, no keys or passwords in build steps, only the packages and ports that are needed. 5. Suggest a multi-stage build if build tools end up in the final image. 6. Output the improved Dockerfile and below it a table: Change · Reason · Effect on size, security or build time. Flag every change that could affect how the application behaves.

Take particular care to justify every change with its reason and effect and never silently change how the application behaves.

Before you answer, check: Are all instructions met? If key information is missing or a placeholder in square brackets is still in the text, ask instead of guessing. Mark assumptions as assumptions.

This is an instruction for an AI, not the result itself.

Where this prompt works

These AI tools are a good fit for this prompt:

How to use it

Fill in the fields or tap a suggestion. Leave out names, addresses and other personal data.
Copy the finished prompt into an AI tool of your choice.
Build the new image locally once, compare size and build time and run the tests before you adopt it.

Why does this work?

The fixed order of checks covers the most common causes of large, slow or risky images. The table with reason and effect makes every change easy to follow in review.

Tips

After switching to a non-root user, check that the application can still write where it needs to, for example logs or temporary files.

You may use our prompts freely, including at work. Please do not republish them as your own collection. We give no warranty for AI results; check them yourself. Terms of use

Review a Dockerfile for size, security and build time

Result preview

Fill in

Your prompt

Where this prompt works

How to use it

Why does this work?

Tips

Part of these agents

Also a good fit

Rollback plan before a release New

Choose pagination for an API list New

Write an API reference people can use right away New