Deployment Patterns
Ship a solo-built web app with repeatable CI/CD, Docker, health checks, rollbacks, and a production-readiness checklist instead of one-off deploy hacks.
Overview
Deployment-patterns is an agent skill most often used in Ship/Launch (also Operate/Infra, Build/Backend) that teaches CI/CD workflows, Docker containerization, rollout strategies, health checks, rollbacks, and production
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill deployment-patternsWhat is this skill?
- Documents rolling and blue-green deployment flows with pros, cons, and when to use each
- Covers CI/CD pipeline patterns for web applications from the ECC deployment-patterns skill
- Guides Docker containerization and environment-specific production configuration
- Explains health checks, readiness probes, and rollback strategies after a bad deploy
- Includes production readiness checklists for solo builders shipping their own stack
Adoption & trust: 5.2k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are ready to ship but lack a consistent CI/CD, container, health-check, and rollback plan, so every release feels risky and hard to undo.
Who is it for?
Solo builders shipping a SaaS, API, or CLI-backed web app who control their own CI/CD and want structured rollout and rollback decisions before traffic moves.
Skip if: Builders who only publish static sites with a one-click host and never touch containers, pipelines, or multi-instance rollouts.
When should I use this skill?
Setting up CI/CD pipelines, dockerizing an application, planning deployment strategy (blue-green, canary, rolling), implementing health checks and readiness probes, preparing for a production release, or configuring envi
What do I get? / Deliverables
After the skill runs, you get actionable deployment strategy choices, pipeline and Docker patterns, probe guidance, and release checklists your agent can turn into configs and runbooks for safer production cutovers.
- CI/CD workflow patterns aligned to your stack
- Docker and environment configuration guidance
- Health-check, rollout, and rollback runbook material for production releases
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill centers on production release mechanics—CI/CD, containerization, rollout strategies, and readiness checks—right before and during go-live. Launch is the best subphase fit for preparing a production release, choosing rollout strategy, and validating probes before traffic cutover.
Where it fits
Dockerize the API and define environment-specific config before the first staging deploy.
Pick rolling vs blue-green rollout and add readiness probes before switching production traffic.
Wire health checks into the pipeline so a bad build fails before users see it.
Document rollback steps and iterate CI/CD after an incident or failed release.
How it compares
Use as a procedural deploy-and-CI/CD playbook instead of asking the agent for ad-hoc Dockerfile and workflow snippets without rollout or rollback context.
Common Questions / FAQ
Who is deployment-patterns for?
It is for solo and indie builders using Claude Code, Cursor, Codex, or similar agents who own shipping web apps and need CI/CD, Docker, health checks, and rollback patterns in one skill.
When should I use deployment-patterns?
Use it in Ship/Launch when setting up pipelines, dockerizing, choosing rolling vs blue-green vs canary, and running production readiness checks; in Operate/Infra when improving deploy safety and rollbacks; and in Build/Backend when first containerizing the app.
Is deployment-patterns safe to install?
Review the Security Audits panel on this Prism catalog page for license, hash, and audit signals before installing; the skill describes deployment workflows and may encourage shell, network, and secrets usage in generated CI/CD—apply your own repo and secret policies.
SKILL.md
READMESKILL.md - Deployment Patterns
# Deployment Patterns Production deployment workflows and CI/CD best practices. ## When to Activate - Setting up CI/CD pipelines - Dockerizing an application - Planning deployment strategy (blue-green, canary, rolling) - Implementing health checks and readiness probes - Preparing for a production release - Configuring environment-specific settings ## Deployment Strategies ### Rolling Deployment (Default) Replace instances gradually — old and new versions run simultaneously during rollout. ``` Instance 1: v1 → v2 (update first) Instance 2: v1 (still running v1) Instance 3: v1 (still running v1) Instance 1: v2 Instance 2: v1 → v2 (update second) Instance 3: v1 Instance 1: v2 Instance 2: v2 Instance 3: v1 → v2 (update last) ``` **Pros:** Zero downtime, gradual rollout **Cons:** Two versions run simultaneously — requires backward-compatible changes **Use when:** Standard deployments, backward-compatible changes ### Blue-Green Deployment Run two identical environments. Switch traffic atomically. ``` Blue (v1) ← traffic Green (v2) idle, running new version # After verification: Blue (v1) idle (becomes standby) Green (v2) ← traffic ``` **Pros:** Instant rollback (switch back to blue), clean cutover **Cons:** Requires 2x infrastructure during deployment **Use when:** Critical services, zero-tolerance for issues ### Canary Deployment Route a small percentage of traffic to the new version first. ``` v1: 95% of traffic v2: 5% of traffic (canary) # If metrics look good: v1: 50% of traffic v2: 50% of traffic # Final: v2: 100% of traffic ``` **Pros:** Catches issues with real traffic before full rollout **Cons:** Requires traffic splitting infrastructure, monitoring **Use when:** High-traffic services, risky changes, feature flags ## Docker ### Multi-Stage Dockerfile (Node.js) ```dockerfile # Stage 1: Install dependencies FROM node:22-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --production=false # Stage 2: Build FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN npm run build RUN npm prune --production # Stage 3: Production image FROM node:22-alpine AS runner WORKDIR /app RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 USER appuser COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules COPY --from=builder --chown=appuser:appgroup /app/dist ./dist COPY --from=builder --chown=appuser:appgroup /app/package.json ./ ENV NODE_ENV=production EXPOSE 3000 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1 CMD ["node", "dist/server.js"] ``` ### Multi-Stage Dockerfile (Go) ```dockerfile FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server FROM alpine:3.19 AS runner RUN apk --no-cache add ca-certificates RUN adduser -D -u 1001 appuser USER appuser COPY --from=builder /server /server EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:8080/health || exit 1 CMD ["/server"] ``` ### Multi-Stage Dockerfile (Python/Django) ```dockerfile FROM python:3.12-slim AS builder WORKDIR /app RUN pip install --no-cache-dir uv COPY requirements.txt . RUN uv pip install --system --no-cache -r requirements.txt FROM python:3.12-slim AS runner WORKDIR /app RUN useradd -r -u 1001 appuser USER appuser 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 . . ENV PYTHONUNBUFFERED=1 EXPOSE 8000 HEALTHCHECK --i