Feature · Build & deploy
Zero-downtime deployments on every push.
A zero-downtime deployment ships a new version without taking your app offline. Runex starts the new container, waits until it passes a health check, then moves traffic over: users never see an error page mid-deploy.
- Health-checked before traffic
- Old version drains cleanly
- Failed deploys never go live
- running
- #127 · serving traffic
- new
- #128 · starting
- health check
- GET /health → 200
- traffic
- switched to #128
- old version
- drained, stopped
- downtime
- none
Definition
What is a zero-downtime deployment?
A zero-downtime deployment replaces a running version with a new one while the app keeps serving requests.
Without it, a deploy stops the old process before the new one is ready, and users hit errors or timeouts in the gap.
Runex closes that gap. The new version starts in its own container alongside the old one, and traffic only switches once the new container responds to its health check.
If the new version never becomes healthy, traffic stays on the old one and the deploy is marked failed: a broken build can't take production down.
How it works
How does Runex deploy without downtime?
Start new, check, switch, stop old. Every deploy follows the same four steps.
-
You
Push to your branch
A new commit triggers a deploy.
-
Runex
Start the new version
It boots next to the running one.
-
Runex
Pass a health check
Traffic waits until it responds.
-
Runex
Switch and drain
Requests move over; the old container stops.
Benefits
Why do zero-downtime deployments matter?
Deploy at noon, not at midnight.
No maintenance windows
Ship during business hours without warning users.
Failures stay contained
Unhealthy versions never receive traffic.
In-flight requests finish
The old container drains before it stops.
Deploy more often
Small, frequent releases become the default.
Compare
Zero-downtime vs blue-green deployment: what's the difference?
Zero downtime is the goal; blue-green is one way to reach it. Blue-green keeps two full environments and flips between them; Runex swaps containers per deploy behind a health check.
| Zero-downtime on Runex | Classic blue-green | |
|---|---|---|
| Environments | One: containers swapped per deploy | Two full copies, blue and green |
| Switch trigger | New container passes a health check | Manual or scripted flip |
| Infrastructure | No duplicate environment to run | Double the infrastructure |
| Setup | Built in | You build and maintain it |
Example
Example: shipping an API change mid-day
An API update ships during peak traffic, and no request fails.
- Push to main on acme/api
- Runex builds and starts the new container
- The health check on /health returns 200
- Traffic shifts to the new version
- The old container finishes open requests, then stops
- Zero failed requests during the deploy
- repository
- acme/api
- health path
- /health
- check
- 200 OK · ready
- switch
- after check passes
- errors
- 0 during deploy
FAQ
Questions developers ask
Short answers about zero-downtime deployments. More in the documentation.
How do you deploy without downtime?
Start the new version before stopping the old one, confirm it's healthy, then switch traffic. Runex does this automatically on every deploy.
What is a health check in deployment?
A request the platform sends to your app, often to a path like /health, to confirm it's ready. A healthy response means it's safe to send users traffic.
What happens if a new deployment fails its health check?
Traffic stays on the current version and the new deploy is marked failed. Check the logs, fix the issue, and push again.
What is a rolling deployment?
A rolling deployment replaces instances one at a time so some are always serving traffic. It's common when an app runs several replicas.
Next step
Ship with zero-downtime deployments today.
Sign up, install the GitHub App, and deploy your first app. It's free to start.