Railway's own domain covered this exact mechanism — start the new version, wait for it to report healthy, switch traffic over, then retire the old one. Render implements the same underlying rolling-deployment principle CI/CD's own domain covers generically, with its own specific configuration and a couple of its own real edge cases.
Intermediate
2 min read
The mechanism, the same shape as every platform that does this correctly
Render starts a new deployment alongside the currently-running one, polls a configured health check path until it responds successfully, then shifts traffic over and only then stops the old instance — the exact same rolling-deployment principle CI/CD & Deployment Pipelines' own domain covers in general terms, and the same specific mechanism Railway's own domain already walked through for its own platform.
Configuring the health check correctly
Health Check Path: /healthz
A health check endpoint should report healthy only once the service can genuinely handle real traffic — not merely "the process started," but "database connections are established, any required cache is warmed, startup migrations have completed." A health check that simply returns 200 OK unconditionally the instant the process starts defeats the entire purpose of this mechanism: Render will happily route real traffic to a deployment that technically responded to the health check but isn't actually ready to serve a real request correctly yet.
A real edge case: what happens if the new deployment never becomes healthy
New deployment fails its health check repeatedly, past a timeout
→ Render marks the deploy as FAILED
→ the OLD deployment keeps serving traffic, untouched
→ zero downtime occurred, but the new code never actually shipped
This is the mechanism's actual safety property, made concrete: a broken deployment that never passes its health check simply never receives traffic at all — production keeps running the last-known-good version indefinitely, and the team gets a clear "deploy failed" signal rather than a silent, partial rollout of broken code to real users. This is a structurally safer failure mode than a deploy mechanism that shifts traffic on a timer regardless of actual health.
Why this makes Render's instant-rollback story weaker than Vercel's, in one specific way
Vercel's own domain covered rollback as re-pointing to an already-built, still-running previous deployment (its own lesson 8) — genuinely instant, because the old deployment never stopped running at all. Render's model, once a new deployment does pass its health check and traffic has shifted, stops the old instance entirely (freeing its resources) — rolling back after that point means redeploying the previous version from scratch, with real build/startup time again, not an instant domain re-point. This is a real, structural difference worth knowing before assuming every platform's "rollback" means the same thing operationally.