Docker and Kubernetes Setup via CLI

You are containerizing your application for the first time. The Dockerfile tutorial gets you a working image in ten minutes — 1.2 GB, running as root, with no health check, no signal handling, and a build cache that invalidates on every code change. The Kubernetes tutorial gets you a pod running — with no resource limits, no readiness probe, no pod disruption budget, and secrets hardcoded in the manifest. Getting from “it works” to “it is production-ready” takes another two days of research. Claude Code collapses that into a single, well-structured conversation.

What You’ll Walk Away With

• A Claude Code workflow for generating optimized, secure Dockerfiles and multi-service Docker Compose stacks from your existing project
• Copy-paste prompts that produce Kubernetes manifests with proper health checks, resource limits, autoscaling, and security contexts
• A Helm chart generation approach that creates parameterized, environment-specific deployments

Production Dockerfiles from Project Analysis

Claude Code reads your project and generates a Dockerfile that fits — not a generic template.

Tip

Copy-paste prompt — optimized Dockerfile:

Analyze my project structure, package.json (or requirements.txt, go.mod), and build configuration. Generate a Dockerfile with: 1) multi-stage build -- separate stages for dependencies, build, and runtime, 2) smallest possible runtime image (distroless or alpine), 3) dependency layer caching (copy lockfile before source code), 4) non-root user with a specific UID/GID, 5) tini as PID 1 for proper signal handling, 6) HEALTHCHECK instruction that calls our health endpoint, 7) only production dependencies in the final image, 8) .dockerignore that excludes tests, docs, .git, and node_modules. Also show me the expected image size.

Claude Code detects whether you are building a Node.js, Python, Go, or multi-language project and generates accordingly. For a Node.js app, it separates the npm ci layer from the COPY . . layer so that dependency installation is cached unless package-lock.json changes. For a Go app, it produces a single static binary in a FROM scratch final stage.

After generation, validate the image:

# Build and check the image size
docker build -t myapp:test . && docker images myapp:test

# Run security scan
docker scout cve myapp:test

# Verify the health check works
docker run -d --name test myapp:test && sleep 5 && docker inspect --format='{{.State.Health.Status}}' test

Then iterate:

The image is 280 MB because it includes the entire node_modules. Switch to a production prune step that removes devDependencies after building, and copy only node_modules and dist to the runtime stage.

Docker Compose for Development

Local development should mirror production as closely as possible. Claude Code generates a Docker Compose stack that includes all your dependencies.

Tip

Copy-paste prompt — development Docker Compose:

Create a docker-compose.yml for local development of our app. We need: 1) our application with hot reload (mount src/ as a volume, run the dev server), 2) PostgreSQL 16 with a health check, persistent volume, and initialization script from scripts/init-db.sql, 3) Redis 7 with persistence, 4) a local SMTP server (Mailpit) for email testing, 5) proper dependency ordering (app waits for postgres and redis to be healthy before starting). Use named volumes for database data. Include a docker-compose.override.yml for development-specific config like exposed ports and debug logging. Do not include production-specific services.

The health check with condition: service_healthy on the depends_on is critical. Without it, your application container starts before PostgreSQL is ready to accept connections, causing startup crashes.

For teams with multiple services:

Extend the Docker Compose to include our microservices: api-gateway (port 3000), user-service (port 3001), order-service (port 3002), and notification-service (port 3003). Each service has its own Dockerfile. Add a shared network, service-to-service communication via container names, and a single command to start the full stack. Also add an Nginx reverse proxy that routes /api/users/* to user-service, /api/orders/* to order-service, etc.

Kubernetes Manifests from Scratch

Kubernetes YAML is verbose and error-prone. Claude Code generates complete, production-ready manifests.

Generate Kubernetes manifests for deploying our application. Include: 1) Deployment with 3 replicas, rolling update strategy (maxSurge 1, maxUnavailable 0), pod anti-affinity to spread across nodes, 2) Service (ClusterIP) pointing to port 3000, 3) Ingress with TLS via cert-manager and rate limiting annotations, 4) ConfigMap for non-secret configuration (LOG_LEVEL, CACHE_TTL), 5) Secret references for DATABASE_URL and API keys (reference external secrets, do not hardcode values), 6) HorizontalPodAutoscaler scaling 3-10 replicas based on CPU (70%) and memory (80%), with scale-down stabilization of 5 minutes, 7) PodDisruptionBudget (minAvailable: 2), 8) resource requests (256Mi memory, 250m CPU) and limits (512Mi memory, 500m CPU), 9) liveness probe on /health, readiness probe on /ready, startup probe with 30-second failure threshold. Set security context to non-root, read-only filesystem, no privilege escalation.

Note

Claude Code generates separate YAML files for each resource type (deployment.yaml, service.yaml, ingress.yaml) rather than one massive file. This makes each resource independently reviewable and patchable with kustomize.

Helm Chart Generation

Helm charts turn your Kubernetes manifests into parameterized, reusable packages.

Tip

Copy-paste prompt — Helm chart from manifests:

Convert our Kubernetes manifests into a Helm chart. Create: 1) Chart.yaml with proper metadata and version, 2) values.yaml with defaults for all configurable parameters (replica count, image tag, resource limits, ingress host, environment variables), 3) templates/ with parameterized versions of our deployment, service, ingress, HPA, and PDB, 4) values-staging.yaml and values-production.yaml overrides (staging uses 2 replicas and a different ingress host, production uses 5 replicas and stricter resource limits), 5) helpers template with standard labels (app.kubernetes.io/name, version, managed-by), 6) NOTES.txt that prints the application URL after install, 7) tests/test-connection.yaml that verifies the service is reachable. Include comments in values.yaml explaining each parameter.

After generation, validate the chart:

# Lint the chart
helm lint ./chart

# Render templates without deploying (dry run)
helm template myapp ./chart -f chart/values-staging.yaml

# Deploy to staging
helm upgrade --install myapp ./chart -f chart/values-staging.yaml -n staging

Container Security

Container security is not optional. Claude Code can harden your containers from the start.

Review our Dockerfile and Kubernetes manifests for security issues. Check: 1) running as root (should be non-root), 2) using latest tag (should pin a specific version), 3) missing security context (should set readOnlyRootFilesystem, allowPrivilegeEscalation: false), 4) secrets in environment variables (should use Kubernetes Secrets or an external secret manager), 5) missing network policies (should restrict pod-to-pod communication), 6) container image from untrusted registry, 7) capabilities that should be dropped. Fix every issue and generate a NetworkPolicy that allows only the required traffic.

Multi-Architecture Builds

If your team uses both Intel and ARM machines (Mac M-series), you need multi-architecture Docker images.

Update our Dockerfile and CI pipeline to build multi-architecture images (linux/amd64 and linux/arm64). Use docker buildx with GitHub Actions cache. The build step should produce a single manifest that Docker automatically resolves to the correct architecture. Also update our docker-compose.yml to use platform: linux/amd64 for services that do not support ARM (like some database images).

When This Breaks

The Docker build is slow because the cache invalidates on every change. Layer ordering matters. The COPY package*.json . must come before COPY . . so that code changes do not invalidate the dependency cache. Ask Claude Code: “Reorder our Dockerfile layers to maximize cache reuse. The dependency installation layer should only rebuild when the lockfile changes.”

Kubernetes pods crash-loop with OOMKilled. The memory limit is too low for your application’s actual usage. Ask Claude Code: “Our pods are getting OOMKilled with a 512Mi limit. Analyze our application’s memory usage patterns and recommend appropriate resource requests and limits. Also add a memory monitoring sidecar that exports usage to Prometheus.”

The Helm chart works in staging but fails in production. Usually a missing value or a hardcoded reference. Ask Claude Code: “Compare our values-staging.yaml and values-production.yaml with the template references. Find any template variable that is used but not defined in one of the values files.”

Docker Compose volumes have permission issues. Files created inside the container are owned by root, but your host user cannot edit them. The non-root user inside the container and your host user have different UIDs. Ask Claude Code: “Fix the volume permission issue by making the container user UID match our host user UID. Add a build arg for USER_UID that defaults to 1000.”

The health check passes but the app is not actually ready. A /health endpoint that just returns 200 does not prove the app can serve traffic. Ask Claude Code: “Update our readiness probe endpoint to check: database connection pool has available connections, Redis is reachable, and the last successful background job ran within the last 5 minutes.”

What’s Next

Deployment Automation Deploy your containerized application with blue-green and canary strategies

CI/CD Pipeline Configuration Build and push container images as part of your automated pipeline

Monitoring and Observability Add observability to your containers with sidecar patterns and Prometheus