Help us improve
Share bugs, ideas, or general feedback.
From hatch3r
Creates hardened container images with multi-stage Dockerfile, non-root user, healthcheck, .dockerignore, docker-compose, Kubernetes manifests, and image scanning. Use for containerizing or hardening artifacts.
npx claudepluginhub hatch3r/hatch3r --plugin hatch3rHow this skill is triggered — by the user, by Claude, or both
Slash command
/hatch3r:hatch3r-containerizeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Companion workflow to the `hatch3r-devops` agent: that agent reviews and authors infrastructure across CI/CD, IaC, and orchestration with apply-step gating; this skill is the focused step-by-step procedure for producing a hardened container image and its local + orchestration manifests. Use this skill when the task is "containerize this service" or "harden this Dockerfile"; escalate to the agen...
Provides expert guidance on Docker containerization including optimization, security hardening, multi-stage builds, orchestration, and production deployment.
Develops secure Docker containers with multi-stage builds, non-root users, minimal Alpine/slim images, Skaffold workflows, and 12-factor principles. For Dockerfiles, container security, and orchestration.
Optimizes Docker containers for performance and security with multi-stage builds, orchestration patterns via Compose/Swarm, and production deployment strategies. Analyzes Dockerfiles, environments, and validates builds.
Share bugs, ideas, or general feedback.
Companion workflow to the hatch3r-devops agent: that agent reviews and authors infrastructure across CI/CD, IaC, and orchestration with apply-step gating; this skill is the focused step-by-step procedure for producing a hardened container image and its local + orchestration manifests. Use this skill when the task is "containerize this service" or "harden this Dockerfile"; escalate to the agent when the work spans pipelines, cloud IaC, or a deployment strategy.
Task Progress:
- [ ] Step 0: Detect ambiguity (P8 B1)
- [ ] Step 1: Pick a minimal base image + plan build/runtime split
- [ ] Step 2: Write the multi-stage Dockerfile
- [ ] Step 3: Harden — non-root USER, dropped privileges, HEALTHCHECK
- [ ] Step 4: Add .dockerignore + verify build context size
- [ ] Step 5: Author docker-compose for local dev
- [ ] Step 6: Author Kubernetes manifest with securityContext
- [ ] Step 7: Scan the image and gate on findings
Two invariants bound every image this workflow produces: it runs as a non-root user, and it ships only runtime artifacts (no build toolchain, no secrets). Steps 2–3 establish both; Step 7 verifies them.
Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per agents/shared/user-question-protocol.md. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: language/runtime + version (drives base-image choice), whether the target is local-dev-only or production orchestration, the orchestrator (plain Docker vs docker-compose vs Kubernetes), whether secrets are needed at build time vs runtime (build-time secrets are an irreversible leak risk), and the registry the final image pushes to.
Fan-out scales with task size; token cost never justifies serializing independent work (rules/hatch3r-fan-out-discipline.md P8 B2; agents/shared/efficiency-patterns.md). Tier boundaries for THIS skill:
Emit sub_agents_spawned: { count, rationale } in your output.
-slim variant, a distroless image, or Alpine where the libc difference is acceptable. A smaller base shrinks attack surface and pull time (Docker best-practices — see References).node:22.5.1-slim, not node:latest). A mutable tag makes the build non-reproducible.Structure the Dockerfile so each FROM begins a stage and the final stage copies only the runtime output:
# --- build stage ---
FROM node:22.5.1-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev
# --- runtime stage ---
FROM node:22.5.1-slim AS runtime
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
COPY --from=build only the artifacts the app needs at runtime — never the source tree, build cache, or dev dependencies.RUN --mount=type=secret,...) for build-time credentials and runtime environment injection for runtime credentials; a secret in any layer is recoverable from the image (OWASP Docker Security — see References).runAsUser (Docker best-practices — see References):RUN groupadd -r app --gid=10001 && useradd -r -g app --uid=10001 app
USER app
USER line is mandatory output of this step.HEALTHCHECK so the orchestrator can detect and restart an unhealthy container — this is CIS Docker Benchmark control 4.6 (CIS — see References):HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD node ./dist/healthcheck.js || exit 1
sudo; its TTY and signal-forwarding behavior is unpredictable. If privilege elevation is unavoidable, use gosu (Docker best-practices — see References).COPY not ADD (ADD's URL-fetch and auto-extract behavior is a footgun); set ENV NODE_ENV=production (or the runtime equivalent) so the app does not load dev tooling..dockerignore excluding .git, node_modules (rebuilt in-image), .env*, test artifacts, CI config, and local build output. This keeps secrets out of the build context and shrinks the upload sent to the daemon..env file reaching the build context is a credential-leak path even if a layer does not copy it — exclude it explicitly..dockerignore missed something.docker-compose.yml (or compose.yaml) that builds the image and wires backing services (database, cache, queue) for local development.environment: / env_file: referencing a gitignored .env; never inline secrets in the compose file.healthcheck: per service and use depends_on: with condition: service_healthy so the app waits for its database to be ready.securityContext that enforces the Dockerfile hardening at the orchestrator layer (Kubernetes hardening — see References):securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
requests and limits (CPU + memory) so a runaway container cannot starve the node.HEALTHCHECK to a readinessProbe and livenessProbe so Kubernetes gates traffic and restarts on the same signal.Secret object or external secret store; never inline credentials in the manifest.docker scout) before pushing. Trivy also runs CIS Docker/Kubernetes benchmark checks (Trivy / CIS — see References).hadolint for the Dockerfile, Docker Bench for Security against the host) and surface findings alongside the CVE report.-slim/distroless variant (Step 1), and .dockerignore excludes node_modules/build output (Step 4). A multi-hundred-MB image usually means the build toolchain leaked into the runtime stage.chown the writable path to the app UID in the build stage. Do not revert to root.readOnlyRootFilesystem: true breaks the app: mount an emptyDir volume at the specific writable path (cache, tmp) the app needs rather than disabling the read-only root.COPY or ARG it into a layer. Use a BuildKit secret mount (RUN --mount=type=secret); if that is unavailable, build the artifact outside the image and COPY only the result.sudo; HEALTHCHECK presentlatest); .dockerignore verified to shrink the build contextsecurityContext (runAsNonRoot, dropped capabilities, read-only root), resource limits, and probeshttps://docs.docker.com/build/building/best-practices/ (accessed 2026-06-02, Docker Docs, official-docs). Source for the minimal-base-image guidance (Step 1), the non-root USER with explicit UID and the no-sudo/gosu rule (Step 3), and COPY-over-ADD. Multi-stage build mechanics (Step 2): https://docs.docker.com/build/building/multi-stage/.https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html (accessed 2026-06-02, OWASP, official-docs). Source for the drop-all-capabilities-then-add-back posture (Steps 6), the no-secrets-in-layers rule (Steps 2–4), and the root-escape blast-radius rationale behind the mandatory non-root user (Step 3). Container-environment controls: OWASP Docker Top 10 https://owasp.org/www-project-docker-top-10/.https://www.cisecurity.org/benchmark/docker and https://www.aquasec.com/blog/trivy-kubernetes-cis-benchmark-scanning/ (accessed 2026-06-02, CIS official-docs + Aqua Security established-library). Source for the HEALTHCHECK requirement (Step 3), the Kubernetes securityContext hardening fields (Step 6), and the Trivy CIS-benchmark image-scan gate (Step 7).