{"id":909,"date":"2026-08-17T23:21:29","date_gmt":"2026-08-17T23:21:29","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=909"},"modified":"2026-08-17T23:21:29","modified_gmt":"2026-08-17T23:21:29","slug":"blue-green-canary-deploys-single-vps-nginx","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/blue-green-canary-deploys-single-vps-nginx\/","title":{"rendered":"Zero-Downtime Deploys on a Single VPS: Blue-Green and Canary Releases with Nginx"},"content":{"rendered":"\n

Deploying a new version of your application should not mean telling users “be right back”. On a single VPS you cannot spin up a second datacenter, but you can still get zero-downtime releases \u2014 because Nginx is a perfectly good traffic switch. With two application directories, two upstream pools, and an atomic reload, you can run blue-green swaps and canary releases without Kubernetes or a load balancer in front. The only prerequisite is a VPS with enough RAM to hold two copies of the app, so check the plans on our VPS comparison table<\/a> if you need headroom.<\/p>\n\n\n\n

Blue-Green with Two Upstreams<\/h2>\n\n\n\n

Blue-green means running the old version (blue) and the new version (green) side by side, then switching traffic at the proxy. With Nginx this is two upstream<\/code> blocks pointing at different ports or sockets, and a default that selects one:<\/p>\n\n\n\n

upstream app_blue {\n  server 127.0.0.1:8001;\n}\nupstream app_green {\n  server 127.0.0.1:8002;\n}\n\n# Point this at the active color\nupstream app_active {\n  server 127.0.0.1:8001;\n}\n\nserver {\n  listen 80;\n  server_name app.example.com;\n  location \/ {\n    proxy_pass http:\/\/app_active;\n    proxy_set_header Host $host;\n    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n  }\n}<\/code><\/pre>\n\n\n\n
To deploy version 2: start it on port 8002, run health checks against 127.0.0.1:8002<\/code>, then flip app_active<\/code> to server 127.0.0.1:8002;<\/code> and reload: nginx -s reload<\/code>. The reload is atomic \u2014 Nginx finishes in-flight requests with the old config and applies the new one to everything after, so no connection is dropped. If the new version misbehaves, flip the pointer back and reload again. Rollback is a config edit, not a redeploy.<\/p>\n\n\n\n
Canary Releases with Weighted Upstreams<\/h2>\n\n\n\n
Blue-green is binary: all or nothing. A canary is graduated \u2014 send 5% of traffic to the new version, watch error rates, then ramp to 25%, 50%, 100%. Nginx does this with upstream weights:<\/p>\n\n\n\n
upstream app_canary {\n  server 127.0.0.1:8001 weight=95;  # blue: 95%\n  server 127.0.0.1:8002 weight=5;   # green: 5%\n}<\/code>\n\n\n\n
Each reload with a new weight is a canary step. Watch three things between steps: HTTP 5xx rate in access.log<\/code>, application error logs, and latency percentiles. If the canary's error rate matches or beats blue's, keep ramping; the moment it spikes, reload with weight=0<\/code> on green and investigate. For a cleaner signal, give the canary its own log file (access_log \/var\/log\/nginx\/canary.log;<\/code> in a server block that only green sees) so you can compare populations instead of averages.<\/p>\n\n\n\n
Header and Cookie-Based Routing: Canary for Specific Users<\/h2>\n\n\n\n
Weighted routing is random; sometimes you want deterministic canaries \u2014 internal testers always see green, everyone else stays on blue. A map<\/code> block decides the upstream per request:<\/p>\n\n\n\n
map $http_cookie $backend {\n  default        app_blue;\n  \"~*canary=1\"   app_green;\n}\n\nserver {\n  location \/ {\n    proxy_pass http:\/\/$backend;\n  }\n}<\/code>\n\n\n\n
Testers visit app.example.com<\/code> with the canary=1<\/code> cookie; everyone else stays on blue. The same pattern works with a header ($http_x_canary<\/code>) for API clients or CI smoke tests. This is the classic staging-inside-production trick: the canary is fully deployed and serving real requests, but only for a population you control.<\/p>\n\n\n\n
A Minimal Deploy Script<\/h2>\n\n\n\n
The whole cycle fits in a short script: deploy to the inactive color, health-check it, switch, verify, and keep the previous version around for rollback.<\/p>\n\n\n\n
#!\/usr\/bin\/env bash\nset -euo pipefail\nAPP_DIR=\/srv\/app\nNEW_PORT=8002   # alternate between 8001\/8002 per release\n\n# 1. Ship code to the inactive color\nrsync -a --delete .\/build\/ $APP_DIR\/green\/\n\n# 2. Start the green app (systemd unit on port 8002)\nsystemctl restart app-green\n\n# 3. Health-check before touching Nginx\nfor i in {1..10}; do\n  curl -fsS http:\/\/127.0.0.1:8002\/healthz && break || sleep 1\ndone\n\n# 4. Switch traffic and reload atomically\nsed -i 's\/server 127.0.0.1:8001;\/server 127.0.0.1:8002;\/' \\\n  \/etc\/nginx\/conf.d\/app.conf\nnginx -t && nginx -s reload\n\n# 5. Post-deploy smoke test through the public entrypoint\ncurl -fsS https:\/\/app.example.com\/healthz<\/code>\n\n\n\n
The two colors can be two systemd units (app-blue.service<\/code>, app-green.service<\/code>), two directories under \/srv\/app\/<\/code>, or two containers \u2014 Nginx does not care, it only balances between the ports. Just ensure the app reads its config from the environment so both colors run with identical settings except the version.<\/p>\n\n\n\n
Where This Breaks (Know the Limits)<\/h2>\n\n\n\n