Scalingo Zero‑Downtime Deployments: How Rolling Updates Keep Your App Online

The Problem

When a new version of a web application goes live, users expect a smooth transition. A brief 5‑second outage can lead to lost conversions, negative reviews, and support tickets. Traditional deployments, which tear down the old container before starting the new one, inevitably create a moment of unavailability. Scalingo tackles this by offering a zero‑downtime deployment that is built on a rolling‑update strategy.

Engineering the Roll‑out

Scalingo’s platform treats each release as a dyno (a container instance). When you push a new Git commit or Docker image, the build pipeline does the following:

• Builds the new image and spins up a new dyno.
• Runs a configured health‑check against the new dyno. The health‑check is a simple HTTP request (e.g., GET /health) that must return a 200‑level status.
• Only after the health‑check passes does the routing layer redirect traffic from the old dyno to the new one.
• The old dyno is then gracefully terminated.

This overlap period ensures that at least one instance is always serving traffic. Because the new dyno is pre‑warm‑ed, the first request it receives is already fully initialized, which also reduces cold‑start latency.

Verifying Zero‑Downtime

To confirm that a deployment truly has no downtime, follow these steps:

1. Trigger a deployment (CLI or dashboard).
2. Open the Deployments tab in the dashboard or run scalingo releases to watch the status change from Deploying to Running.
3. Inspect the logs for the sequence:
   • "Starting new release"
   • "Health check passed"
   • "Swapping traffic"
4. Run a lightweight HTTP script that polls the app during the transition. Example:

   #!/usr/bin/env bash
   URL="https://myapp.scalingo.com"
   for i in {1..10}; do
     HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
     echo "[$i] $URL returned $HTTP_CODE"
     sleep 2
   done
   

   If any of the responses are 5xx during the transition, the deployment did not achieve zero downtime.

Trade‑offs and Limits

Aspect	Impact
Resource Overhead	During overlap, two dynos run simultaneously, effectively doubling CPU/memory usage for that period.
Health‑Check Sensitivity	If the check is too strict or the app takes a long time to start, the deployment stalls, extending the overlap and cost.
Stack Compatibility	Not all runtime stacks support rolling updates. Verify that your stack (Node.js, Ruby, Python) is listed in Scalingo’s docs.
Cold‑Start Mitigation	Pre‑warming helps, but if the new dyno still experiences a cold start, the first few requests may be slower.

Because the platform relies on correctly configured health‑checks, misconfiguration can cause traffic to remain on the old release, nullifying the zero‑downtime guarantee.

Take‑away

Scalingo’s zero‑downtime deployment is a practical, engineered solution that keeps your users online during releases. By understanding the rolling‑update flow, configuring robust health‑checks, and validating deployments with simple scripts, you can confidently release new features without service interruption. Keep an eye on the overlap period’s resource usage and adjust health‑check thresholds to balance reliability with cost.