Multi-stage Dockerfile authoring guidance
multi-stage-dockerfile
Draft multi-stage Dockerfiles that separate build-time work from runtime artifacts and organize layers, base images and runtime permissions.
Introduction source: author · GitHub, Inc. · b6483db44fb602654bca6a097185fcaddb305f97 Reference
Author's original introduction
Create optimized multi-stage Dockerfiles for any language or framework
SkillPi interpretation
- Tasks
- Design builder/runtime stages, artifact copying, caching, .dockerignore and non-root runtime configuration.
- Audience
- Developers containerizing an application with Docker.
- Inputs and outputs
- Input: application language/framework and build/runtime requirements. Output: Dockerfile structure and configuration guidance.
- Software, accounts and paid services
- Docker tooling and appropriate base images/dependencies for the target application. No specific paid account is stated. Confirm actual file access and external-service permissions in your host. Domains referenced in the documents (not a runtime allowlist): No HTTP(S) domain stated.
- Limits and differences
- Smaller or safer images are design goals, not measured results. Generated images still need builds and vulnerability scans; no source command was executed here.
- Testing
- Not tested
Security rating and access scope
caution · Static evidence review; not a runtime safety guarantee.
Docker tooling and appropriate base images/dependencies for the target application. No specific paid account is stated. Confirm actual file access and external-service permissions in your host. Domains referenced in the documents (not a runtime allowlist): No HTTP(S) domain stated.
Before use, confirm and authorize actual file access, external services and network destinations in your host. This review grants no runtime permissions.
Original SKILL.md
--- name: multi-stage-dockerfile description: 'Create optimized multi-stage Dockerfiles for any language or framework' --- 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
Copyright and license notice
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.
User discussion