← ClaudeAtlas

dockerfile-backendlisted

Multi-stage Dockerfiles for Python/FastAPI backends — builder vs runtime, slim vs alpine, system deps, layer caching, non-root users. Use when containerizing or optimizing Python backend images.
ajyadav013/claude-kit · ★ 12 · AI & Automation · score 72
Install: claude install-skill ajyadav013/claude-kit
# Dockerfile for Python Backend Services Multi-stage Dockerfile patterns for Python/FastAPI backend services, covering base image selection, system dependencies, layer caching, security hardening, and multi-mode entrypoints. ## When to use - Containerizing Python backend services (FastAPI, Flask, Django) - Optimizing Docker build times through effective layer caching - Minimizing production image sizes with multi-stage builds - Installing system dependencies for Kafka clients, PostgreSQL, or Kerberos authentication - Implementing secure container images with non-root users - Setting up multi-mode entrypoints (server/consumer/worker/cron from one image) - Debugging production Dockerfile build failures or runtime issues ## Core conventions ### Base Image Selection: Slim vs Alpine **Python slim (Debian-based)**: Use `python:3.11-slim` or `python:3.12-slim` for broader compatibility with compiled extensions (psycopg2, cryptography, numpy). Larger base (~150MB) but fewer build issues. **Python alpine**: Use `python:3.10-alpine3.20` or `python:3.11-alpine` for minimal footprint (~50MB). Requires more build dependencies (g++, musl-dev, libffi-dev) and may have compatibility issues with some wheels. **Recommendation**: Start with slim for faster development; switch to alpine only if image size is critical and you've verified all dependencies build correctly. ### Multi-Stage Builds: Builder + Runtime **Builder stage**: Install all build tools, compile dependencies, create vi