production-dockerfile
Creates optimized, secure multi-stage Dockerfiles for Python applications.
Install
mkdir -p .claude/skills/production-dockerfile && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14193" && unzip -o skill.zip -d .claude/skills/production-dockerfile && rm skill.zipInstalls to .claude/skills/production-dockerfile
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Generate production-ready Dockerfiles with multi-stage builds, security best practices, and optimization. Use when containerizing Python applications for production deployment.Key capabilities
- →Separate build dependencies from runtime dependencies
- →Use UV package manager for faster dependency installation
- →Start with Alpine Linux base images
- →Add HEALTHCHECK instruction to Dockerfiles
- →Create and switch to a non-root user for runtime
How it works
The skill generates Dockerfiles using multi-stage builds to separate build dependencies from runtime, reducing image size and attack surface. It incorporates best practices like using Alpine base images, UV for package management, and non-root users for security.
Inputs & outputs
When to use production-dockerfile
- →Containerizing Python microservices
- →Optimizing Docker image size
- →Securing containerized applications
- →Configuring health checks for Kubernetes
About this skill
Production Dockerfile Skill
Persona
Think like a DevOps engineer who optimizes container images for production Kubernetes deployments. You balance image size, build speed, security, and operational simplicity. You've containerized hundreds of Python services and know the common pitfalls.
Analysis Questions
Before generating a Dockerfile, analyze the project by asking:
-
Deployment Target: Kubernetes cluster, Docker Compose, bare Docker, or serverless container (Cloud Run, Fargate)?
-
Base Image Strategy: What constraints apply?
- Security requirements (must use approved base images?)
- Size requirements (bandwidth-constrained environment?)
- Compatibility requirements (native extensions that need glibc?)
-
Large Files: Are there model files (>100MB) or data that should be volume-mounted rather than baked into the image?
-
Security Requirements:
- Must run as non-root user?
- Read-only filesystem required?
- Specific UID/GID requirements?
-
Health Monitoring: What endpoints indicate service health?
- Simple HTTP ping (/health)?
- Database connectivity check?
- Downstream service availability?
-
Build Context: What files should be excluded?
- .git directory?
- Test files?
- Local environment files (.env)?
Principles
Apply these non-negotiable principles to every Dockerfile:
P1: Multi-Stage Always
Separate build dependencies from runtime. Build stage installs compilers, dev packages. Runtime stage contains only what's needed to run.
Why: Reduces image size from 500MB+ to under 200MB. Removes attack surface from build tools.
P2: UV for Speed
Use UV package manager instead of pip. UV is 10-100x faster for dependency installation.
RUN pip install uv
RUN uv pip install --system --no-cache -r requirements.txt
Why: Faster CI/CD builds. No cache pollution.
P3: Alpine Default
Start with Alpine Linux base images. Fall back to slim only if native extensions fail.
FROM python:3.12-alpine # First choice
FROM python:3.12-slim # Fallback if alpine breaks
Why: Alpine images are 5-10x smaller. Most Python services work fine on Alpine.
P4: Health Checks Mandatory
Every production container needs a HEALTHCHECK instruction.
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
CMD wget --no-verbose --tries=1 --spider http://localhost:8000/health || exit 1
Why: Kubernetes/Docker orchestrators need health signals for rolling deployments.
P5: Non-Root Default
Create and switch to a non-root user for runtime.
RUN adduser -D -u 1000 appuser
USER appuser
Why: Container escape vulnerabilities are less severe without root.
P6: Environment Configuration
All configuration via environment variables. Never hardcode URLs, credentials, or environment-specific values.
ENV PYTHONUNBUFFERED=1
# Database URL provided at runtime: -e DATABASE_URL=...
Why: Same image works in dev, staging, production.
P7: No Secrets in Image
Never COPY .env files or credentials into the image. Use runtime environment variables or secret mounting.
Why: Images are often pushed to registries. Secrets in images = secrets exposed.
Output Format
Generate Dockerfiles with this structure:
# =============================================================================
# Stage 1: Build
# =============================================================================
FROM python:3.12-alpine AS builder
WORKDIR /app
# Install build dependencies
RUN apk add --no-cache gcc musl-dev # Only if needed for native extensions
RUN pip install uv
# Install Python dependencies
COPY requirements.txt .
RUN uv pip install --system --no-cache -r requirements.txt
# =============================================================================
# Stage 2: Runtime
# =============================================================================
FROM python:3.12-alpine
# Create non-root user
RUN adduser -D -u 1000 appuser
WORKDIR /app
# Copy dependencies from builder
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin
# Copy application code
COPY --chown=appuser:appuser . .
# Environment configuration
ENV PYTHONUNBUFFERED=1
# Switch to non-root user
USER appuser
# Health check
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
CMD wget --no-verbose --tries=1 --spider http://localhost:8000/health || exit 1
# Expose port
EXPOSE 8000
# Start command
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Invocation Examples
When to use this skill:
- "Containerize this Python application"
- "Create a Dockerfile for my FastAPI service"
- "Help me optimize my Docker image"
- "Make my container production-ready"
Example prompt:
Use the production-dockerfile skill to containerize my FastAPI service.
It connects to PostgreSQL and needs to run in Kubernetes.
Here's my requirements.txt: [paste]
When not to use it
- →When deploying simple applications not requiring production-grade containerization
- →When the application is not Python-based
Limitations
- →Alpine base images may not work for all native extensions
- →Secrets must not be copied into the image
How it compares
This approach focuses on optimizing Docker images for production Kubernetes deployments by balancing image size, build speed, security, and operational simplicity, unlike generic Dockerfile creation.
Compared to similar skills
production-dockerfile side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| production-dockerfile (this skill) | 0 | 4mo | Caution | Intermediate |
| devops-python-engineer | 0 | 4mo | No flags | Advanced |
| deployment-engineer | 4 | 4mo | No flags | Advanced |
| devops-engineer | 1 | 3mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by phenobarbital
View all by phenobarbital →You might also like
devops-python-engineer
lek-x
DevOps and Python service delivery for repositories that need build or runtime debugging, CI/CD changes, containerization, deployment automation, infrastructure updates, observability improvements, or backend Python code changes. Use when Codex must act like a DevOps engineer who can also implement
deployment-engineer
sickn33
Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.
devops-engineer
Jeffallan
Use when setting up CI/CD pipelines, containerizing applications, or managing infrastructure as code. Invoke for pipelines, Docker, Kubernetes, cloud platforms, GitOps.
devops-engineer
I-Synergy
DevOps and CI/CD specialist. Use for building pipelines, containerization, infrastructure as code, or deployment automation. User-invocable only for production deployments.
platform-engineering
villadalmine
>-
add-linux-bootstrap-platform
ponylang
Load when adding a new Linux distro/version (e.g. Alpine 3.24, Ubuntu 26.04) — or both arches for an existing one — as a fully supported ponyup bootstrap-test target. Covers the bootstrap-tester Dockerfile, image build dispatch and tag discovery, CI workflow updates (tier 1 / tier 2), ponyup-init.sh