Multi stage dockerfile

Skill FluxonLab/Skillry/community/github-awesome-copilot/skills/multi-stage-dockerfile

Create optimized multi-stage Dockerfiles for any language or frameworkFrom its SKILL.md

Install

npx -y skills add FluxonLab/Skillry --skill multi-stage-dockerfile

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.3 KB, 419 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most containers cloud skills give in 419 tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

Run containers as a non-root userhere, and in 66 of 607, across 46 files
Use multi-stage buildsin 53 of 607, across 44 files
Use Promise.all for independent operationsin 47 of 607, across 13 files
Import directly instead of barrel filesin 46 of 607, across 12 files
Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
Create a .dockerignore filein 41 of 607, across 31 files
Read individual rule files for detailsin 39 of 607, across 9 files
Copy dependency files before source codein 36 of 607, across 23 files
Authenticate server actions like API routesin 35 of 607, across 7 files
Use next/dynamic for heavy componentsin 34 of 607, across 9 files
Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.