- Shipped
- 4 Septemba 2026, 20:39 UTC
- Author
- Kamo
- Commit
- 7ea8f7f
Next handles SIGTERM with a bare process.exit(143), so every deploy severed whatever this pod had in flight — a form post, a server action, a streamed RSC payload, an upload. Invisible when a request lasted milliseconds; not invisible on a cluster that deploys on every push. scripts/standalone-entry.cjs wraps the standalone server: on SIGTERM it stops accepting, drops idle keep-alives at once so a pod with nothing in flight still exits in about a second, and lets running requests finish under a cap that sits below terminationGracePeriodSeconds. Ported from kamo-internal, which has run it in production for months. This deployment had no readiness probe, so a pod counted as Ready the instant its container process started. With maxUnavailable 0 Kubernetes reads that as "the new pod is serving" and retires the old one — while Next is still initialising and has not bound its port. Requests landed on a port nothing was listening on, which is where the intermittent 502s on deploy came from. /api/health answers only for this pod and deliberately touches no backend: a readiness probe decides whether this pod leaves the Service, and wiring it to a backend turns a backend blip into a rolling restart of every pod here. Already at two replicas; this is what makes the second one actually cover the first during a rollout rather than both being replaced blind.