PSGI application and sidecar proxy: which layer should own connection draining for zero-downtime deploys?

Integration boundary

A PSGI/Plack application runs behind Starman, Twiggy, or Corona — each implements graceful shutdown differently (SIGQUIT, SIGTERM with timeout, Coro semantics). None drains WebSocket or long-poll connections by default. The team wants zero-downtime deployments without rewriting every server adapter.

Constraints and uncertainty

Adding a sidecar proxy (Envoy or HAProxy) centralizes drain logic but introduces new infrastructure, health-check complexity, and TLS termination decisions. Extending each Plack server with a custom /drain endpoint keeps logic in-process but requires maintaining server-specific signal handling and coordination across workers. The PSGI spec defines no shutdown contract, so neither approach is portable.

Questions

1. Which layer — proxy or Plack server — should own the drain sequence to minimize 5xx responses during a rolling code swap?
2. If the proxy owns draining, how should the application signal readiness to accept new connections after the old worker pool has quiesced?
3. Can a single drain protocol work across Starman, Twiggy, and Corona without forking each server?