What this prompt does
This prompt makes the AI a senior DevOps engineer that returns a working slimmer Dockerfile and a real reduction plan, not a list of tips. You provide the [app_language], the [current_size], the [target_size], and your [dockerfile]. It audits where the bloat comes from (base image, build tools, dev dependencies, caches), introduces a multi-stage build that ships only the runtime artifact, swaps to a distroless or alpine base justified for your language, prunes dev dependencies and removes compilers from the final stage, adds a .dockerignore and squashes layers where it helps, and states the estimated final size and the single biggest contributor to the reduction.
The structure works because it diagnoses the bloat before rewriting, so the changes target real weight rather than guesswork that may not move the needle. [app_language] justifies the base-image choice; what is safe to strip for one runtime differs for another. [current_size] and [target_size] frame the goal and let the model say whether the target is realistic for your runtime or wishful. Pasting your actual [dockerfile] is what lets the audit name specific lines and layers rather than speak in generalities. The fastest win is usually the multi-stage split that leaves the compiler and dev dependencies behind in the build stage, not merely picking the slimmest base image.
When to use it
- A bloated image slows every pull, autoscale event, and cold start.
- You want a diagnosis of where the size actually comes from, not generic tips.
- You are preparing an image for production scaling.
- You want a multi-stage rewrite that ships only the runtime artifact.
- You need the base-image swap justified for your specific language.
- You want an estimated final size and the biggest single contributor named.
Example output
You get a bloat audit naming the main contributors (base image, build tools, dev dependencies, caches), the fully rewritten multi-stage Dockerfile, a matching .dockerignore, and a size-reduction breakdown that states the estimated final size and the single biggest contributor to the cut. It is delivered as a working Dockerfile plus the reasoning behind each change, so you can both apply it and understand why the image shrank rather than just receiving a list of generic tips you have to act on yourself.
Pro tips
- Paste the complete current
[dockerfile]so the audit can name specific bloated lines. - State
[current_size]and[target_size]so the model can judge if the target is realistic. - Set
[app_language]accurately; it justifies whether distroless or alpine is safe. - Expect the multi-stage split to be the biggest win, not the slimmest base image.
- Confirm the .dockerignore excludes node_modules, build output, and caches.
- Test the slimmed image end to end; an over-aggressive base can drop a runtime dependency.
