deployment-patterns

Use rolling deployments for standard backward-compatible changes, blue-green for critical services needing instant rollback, and canary for high-traffic services or risky changes where you want real-traffic validation before full rollout.

Expose a /health endpoint returning HTTP 200, then configure liveness, readiness, and startup probes pointing at it. Use a startup probe with a high failureThreshold so slow-starting containers are not killed prematurely.

Liveness probes detect deadlocked containers and trigger restarts, while readiness probes control whether a pod receives traffic. A failing readiness probe removes the pod from service without restarting it.

Define a schema with a library like Zod covering required variables such as DATABASE_URL and JWT_SECRET, then parse process.env at startup. The application fails fast with a clear error instead of misbehaving later.

Ensure the previous image is tagged and available, database migrations are backward-compatible, feature flags can disable new functionality, and error-rate alerts are configured. Test the rollback in staging before the production release.

Avoid canary deployments when you lack traffic-splitting infrastructure or monitoring to compare versions, and when changes are not backward-compatible across simultaneously running versions. Small low-traffic services gain little from the added complexity.