Why deploys drop requests
When you deploy, the orchestrator stops the old version. If it sends a kill signal and the process dies instantly, anyone mid-request gets a reset connection or a 5xx. The goal is to make "stop" mean "finish what you're doing first, then exit" — a graceful shutdown.
The three moving parts
1. Flip to 'not ready'
Fail the readiness check first so the load balancer drains you before you stop accepting connections.
2. Handle SIGTERM
Stop accepting new requests, let in-flight ones finish, close DB and queue connections, then exit 0.
3. Drain timeout
If draining hangs, force-exit before the platform's SIGKILL does — so you control the outcome.
The deploy sequence that drops nothing
Put together, a zero-drop rollout looks like this:
1. Start the NEW instance, wait until it passes readiness.
2. Add it to the load balancer.
3. Flip the OLD instance's readiness to false (stop new traffic).
4. Send SIGTERM to the old instance.
5. Old instance: finish in-flight requests, close connections, exit.
6. (Safety) force-exit if draining exceeds the grace period.At no point is there an instance receiving traffic it can't serve, and no request is cut off mid-flight.
The keep-alive gotcha
One subtle trap: HTTP keep-alive connections stay open between requests, and server.close() waits for them. Set a short keepAliveTimeout, or actively close idle connections during shutdown, or your "graceful" drain hangs until the timeout fires every single deploy.
Errors you might hit
The specific errors that mean you're dropping requests:
Draining handled by the agent
Infraveil coordinates new-instance startup, health checks, and configured draining before an old managed instance stops. Operate releases and recovery from one control plane while the application runs on your servers. Test your application's shutdown handler and proxy path: the configured sequence helps preserve requests, but request continuity depends on those components working together.
Frequently asked questions
Why does my app drop requests on deploy?
Because the old process was stopped while still serving traffic. Either it didn't handle SIGTERM, or it didn't drain in-flight requests before exiting, so the platform's forced kill cut them off.
What is connection draining?
Letting an instance finish the requests it's already handling before it shuts down, while no longer accepting new ones. It's the core of a graceful, zero-drop deploy.
What's a readiness flip?
Marking an instance "not ready" so the load balancer stops routing new requests to it — done first, before shutdown, so traffic moves away before the process stops.
How long should the drain timeout be?
Slightly longer than your slowest normal request, but shorter than the platform's kill grace period (often 30s). Force-exit at that point so you control shutdown rather than getting SIGKILLed mid-request.
Client-side, no signup — they run in your browser.