deployment-patterns

Use separate stages for dependency installation, building, and the production runtime. Copy only production node_modules and build output into the final stage, run as a non-root user, pin a specific base image tag like node:22-alpine, and add a HEALTHCHECK instruction.

Blue-green runs two identical environments and switches all traffic atomically, giving instant rollback at the cost of double infrastructure. Canary routes a small traffic percentage to the new version first, catching issues with real traffic but requiring traffic-splitting and monitoring infrastructure.

Structure the pipeline as test, build, and deploy jobs. The test job runs lint, typecheck, and tests; the build job uses docker/build-push-action to push a tagged image to a registry like ghcr.io; the deploy job runs only on the main branch with a production environment gate.

Yes, they serve different purposes. Liveness probes restart unhealthy containers, while readiness probes control whether a pod receives traffic. A startup probe should also be added for slow-starting applications to prevent premature liveness failures.

For Kubernetes, run kubectl rollout undo on the deployment to return to the previous image. Platforms like Vercel and Railway support promoting a previous deployment or commit. Ensure database migrations are backward-compatible so rollbacks do not break the older version.

Validating configuration at startup with a schema library like zod makes the application fail fast with a clear error instead of crashing later in production. It enforces required values such as DATABASE_URL and JWT_SECRET before the server accepts traffic.