Generated banner for Multi Stage Dockerfile
Generated logo for Multi Stage Dockerfile

Multi Stage Dockerfile

GitHubOfficialOriginally contributed by @aaronpowell as prompts/multi-stage-dockerfile.prompt.md; moved into a skill by pull request #761Distributed by GitHub

  • Skill
  • Content generator
  • Cloud and DevOps
  • MIT
  • No issues found

From the author

Create optimized multi-stage Dockerfiles for any language or framework
— the description by aaronpowell

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to building container images using multi-stage Dockerfiles. It emphasizes reducing image size, improving security, and optimizing build performance by separating build-time dependencies from runtime requirements. The guidelines cover best practices for base image selection, layer caching, and security configurations.

What it does

  • Defines a multi-stage structure using builder and runtime stages.
  • Recommends minimal base images and specific version tagging.
  • Provides strategies for maximizing layer caching efficiency.
  • Outlines security practices like using non-root users.
  • Suggests performance optimizations for container runtimes.

When to use it

  • When you need to reduce the size of your container images.
  • When you want to improve the security posture of your application containers.
  • When you are setting up a new containerized project.
  • When you need to optimize build times through better layer caching.

Advantages

  • Smaller final image footprints.
  • Reduced attack surface by excluding build tools from runtime.
  • More reproducible builds through specific versioning.
  • Improved build performance via efficient layer ordering.

Usage examples

“How should I structure a Dockerfile for a Python application to keep it small?”
The agent will provide a multi-stage Dockerfile template using a builder stage for dependencies and a slim runtime stage, ensuring only necessary artifacts are copied.
“What are the best practices for securing a container image?”
The agent will advise on using non-root users, removing unnecessary build tools, and using multi-stage builds to exclude secrets from the final image.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/multi-stage-dockerfile/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip multi-stage-dockerfile.zip -d .agents/skills

Documentation by aaronpowell

Your goal is to help me create efficient multi-stage Dockerfiles that follow best practices, resulting in smaller, more secure container images.

Multi-Stage Structure

  • Use a builder stage for compilation, dependency installation, and other build-time operations

  • Use a separate runtime stage that only includes what's needed to run the application

  • Copy only the necessary artifacts from the builder stage to the runtime stage

  • Use meaningful stage names with the AS keyword (e.g., FROM node:18 AS builder)

  • Place stages in logical order: dependencies → build → test → runtime

Base Images

  • Start with official, minimal base images when possible

  • Specify exact version tags to ensure reproducible builds (e.g., python:3.11-slim not just python)

  • Consider distroless images for runtime stages where appropriate

  • Use Alpine-based images for smaller footprints when compatible with your application

  • Ensure the runtime image has the minimal necessary dependencies

Layer Optimization

  • Organize commands to maximize layer caching

  • Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)

  • Use .dockerignore to prevent unnecessary files from being included in the build context

  • Combine related RUN commands with && to reduce layer count

  • Consider using COPY --chown to set permissions in one step

Security Practices

  • Avoid running containers as root - use USER instruction to specify a non-root user

  • Remove build tools and unnecessary packages from the final image

  • Scan the final image for vulnerabilities

  • Set restrictive file permissions

  • Use multi-stage builds to avoid including build secrets in the final image

Performance Considerations

  • Use build arguments for configuration that might change between environments

  • Leverage build cache efficiently by ordering layers from least to most frequently changing

  • Consider parallelization in build steps when possible

  • Set appropriate environment variables like NODE_ENV=production to optimize runtime behavior

  • Use appropriate healthchecks for the application type with the HEALTHCHECK instruction

Files

LICENSE

MIT License

Copyright GitHub, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python, Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Originally contributed by
GitHub avatar of aaronpowell@aaronpowellas prompts/multi-stage-dockerfile.prompt.mdmoved into a skill by pull request #761
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/multi-stage-dockerfile · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
CypherHK, aaronpowell, jamesmontemagno

AutoGineer is not affiliated with or endorsed by aaronpowell or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download multi-stage-dockerfile.zip