Insights · Engineering

Zero-downtime deploys without a platform team

Blue-green releases with nothing more than Nginx and a shell script.

Not every company needs Kubernetes. Plenty of healthy businesses run on two or three virtual servers — and still deserve releases that don't show users an error page. Here is the setup we use most often for small and mid-size clients.

The idea: two copies, one switch

Blue-green deployment means you run two copies of your application side by side — call them blue and green. Only one receives traffic. You deploy the new version to the idle copy, test it, and then flip the switch.

The switch is Nginx

Nginx already sits in front of most web applications. Point its upstream at a small include file that names the active port. A deploy script then:

1. Starts the new release on the idle port.
2. Polls a /health endpoint until it answers correctly — or gives up and aborts.
3. Rewrites the include file to point at the new port.
4. Runs nginx -t and a graceful reload. Existing connections finish on the old copy; new ones go to the new copy.
5. Keeps the old copy running for ten minutes, just in case.

Rolling back is the same script pointed the other way. It takes about two seconds.

The part people forget: the database

Both versions of the code will talk to the same database for a while, so migrations must be backwards compatible. We follow an expand → migrate → contract rule: add new columns first, ship code that writes to both, and only remove old columns in a later release.

What it costs

About a day of setup and roughly double the memory during a deploy. In exchange, releases stop being events — and teams that aren't afraid to deploy ship smaller, safer changes more often.

← All insights