Ship new versions with no dropped requests using a simple blue-green pattern and Nginx.
Cloud & DevOpsPDF · 7 pages· v1.0
4.9A practical, no-Kubernetes approach to deploying new versions of a web app without dropping a single request, using a blue-green pattern on a single VPS with Docker and Nginx. Most small teams restart their app in place and accept a few seconds of downtime and failed requests on every deploy. This guide shows a better way that still fits on one server: run two copies of your app (blue and green), bring the new one up and health-check it, then atomically switch Nginx's upstream to point at it. Old version stays running until the new one is proven healthy, so rollback is instant. You'll set up the two app instances with Docker, write a parameterized Nginx upstream you can flip, add a real health-check gate so traffic only switches when the new version is ready, and wrap the whole thing in a single deploy script. The guide covers graceful connection draining, database migration ordering (the part people get wrong), and how to roll back in seconds. After this guide you'll deploy with confidence: users keep their sessions, in-flight requests complete, and a bad release is one command to undo. For single-server setups; the pattern scales conceptually to load balancers too.
No. This runs on one VPS with Nginx and Docker. The same idea extends to load balancers, but you don't need them to get zero-downtime.
The old (blue) version keeps running. If the new one misbehaves, you flip Nginx back — a one-command, few-second rollback.
The guide explains expand/contract migrations so both versions can run against the schema during the switch. This is the part most tutorials skip.
No. Nginx finishes existing connections on reload and you drain the old instance before stopping it.
Read the full refund policy and trust & safety terms.