Make my deploys zero-downtime. Right now every deploy causes a brief outage or drops in-flight requests, which is fine at zero users and embarrassing once real ones are on the site. Cover each piece: 1. Rolling deploys: the platform should bring up new instances, wait for them to pass readiness checks, shift traffic to them, and only then shut down the old ones. Verify this is what my host is actually doing; some default to stop-then-start, which is a hard downtime window. 2. Graceful shutdown: when the old instance receives SIGTERM, it should stop accepting new requests, finish the ones in flight (up to a reasonable timeout), close database connections cleanly, and only then exit. Implement handlers for SIGTERM and SIGINT that do this. 3. Readiness gate: use the /ready endpoint (from the health-check prompt) as the traffic gate. The platform must not route to a new instance until /ready returns 200. This prevents the classic 'traffic hit the instance before the database pool was ready' first-request 500. 4. Sessions and websockets: sticky sessions or shared session storage so a user isn't logged out mid-deploy. Websocket clients should reconnect (see the websocket scaling prompt) rather than sit dead. 5. Migrations: schema changes must be backwards-compatible so old and new instances can run against the same database during the rollover. Use the additive two-deploy pattern for anything destructive. 6. Long-running background jobs: they should be safe to interrupt (idempotent, checkpointed) so a redeploy doesn't corrupt state or lose work. Don't paper over the issue with a maintenance page every deploy; the goal is invisible deploys. The deliverable is the rolling-deploy config verified, graceful shutdown handlers implemented, the readiness gate wired up, and a live test where a deploy under simulated traffic drops zero requests.