dockerfile

Create secure multi-stage Dockerfiles with non-root users and Docker-based CI builds.

2|Updated May 14, 2026
One-click install
npx skills add https://github.com/AnthonyPoschen/agent-skills --skill dockerfile-anthonyposchen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dockerfile
Source: https://github.com/AnthonyPoschen/agent-skills/tree/main/skills/dockerfile
Command: npx skills add https://github.com/AnthonyPoschen/agent-skills --skill dockerfile-anthonyposchen

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing Dockerfiles by hand often leads to bloated images, root-user containers, and CI pipelines that duplicate build logic outside the Dockerfile. This Skill provides a consistent policy and proven patterns for producing minimal, secure, reproducible container builds. ## Core Features & Use Cases - Multi-stage build design: Separates build, test, and runtime stages so compilers, package managers, and source code stay out of the final image. - Scratch and Alpine final images: Chooses scratch for static binaries and Alpine-based runtimes for Python, Node, or dynamic binaries, with a clear decision order. - Non-root enforcement: Standardizes ARG UID=10001 / ARG GID=10001, COPY --chown, and USER ${UID}:${GID} in every runtime image. - Docker as local CI: Runs tests inside the build (e.g., go test ./..., pytest) so GitHub Actions can be a thin docker build wrapper. - Use Case: Containerize a Go service by generating a multi-stage Dockerfile that compiles a static binary, runs tests in a build stage, and ships a scratch final image running as a non-root user. ## Quick Start Use the dockerfile skill to create a secure multi-stage Dockerfile for this project.

Frequently Asked Questions about dockerfile

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a multi-stage Dockerfile for a Go application?▼

Use a golang alpine build stage to compile a static binary with CGO_ENABLED=0, run go test in the build, then copy only the binary and CA certificates into a scratch final image. Run it as a non-root numeric UID/GID with an exec-form ENTRYPOINT.

Should I use scratch or Alpine as my final Docker image?▼

Use scratch when the output is a single static binary that needs no interpreter or shared libraries. Use Alpine when the app needs a runtime like Python or Node, or requires libc, certificates, or timezone data.

How do I run a Docker container as a non-root user?▼

Declare ARG UID=10001 and ARG GID=10001, create a user and group from those args in Alpine images, and set USER ${UID}:${GID}. Copy application files with COPY --chown=${UID}:${GID} so the runtime user owns them.

Can I run tests inside a Docker build?▼

Yes, add a dedicated test stage running commands like go test ./..., cargo test --locked, npm test, or pytest. Have the production stage depend on the tested artifact, or document docker build --target test for CI.

When should I not use a scratch base image?▼

Avoid scratch when the binary requires CGO, dynamic linking, or runtime shared libraries, unless you intentionally copy and verify every needed library. Also include CA certificates when the binary makes outbound TLS connections.