Nginx · The edge of your stack

How would you do a blue-green deployment with Nginx?

Hardblue-greendeploymentreloadUpdated Oct 2026
Quiz this track

Short answer

Run two identical environments, warm and verify the new one, switch the upstream include or routing rule, reload Nginx gracefully, and keep the old environment available for rollback until connections drain.

Blue-green reduces deployment risk by keeping the previous version running while the new version receives traffic. Nginx's role is to switch upstreams atomically and reload without dropping in-flight requests.

nginx
upstream app {
    include /etc/nginx/upstreams/app-active.conf;
}

server {
    location / {
        proxy_pass http://app;
        proxy_next_upstream error timeout http_502 http_503;
    }
}
The included file contains one or more server lines; switching it changes the active environment.

Safe switch sequence

  • Deploy the green environment and run smoke and health checks before sending user traffic
  • Update the include file atomically, run nginx -t, then reload
  • Watch error rate and latency while old workers drain in-flight requests
  • Keep blue running until the rollback window closes, then scale it down
  • Make database migrations backward compatible so both versions can run at once
  • Use sticky sessions only when necessary; shared session storage is easier to switch
A reload is graceful for requests already in flight, but long-lived WebSockets can keep old workers alive. Drain them at the load balancer and set worker_shutdown_timeout so the switch does not hang.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you switch traffic without downtime?
  2. 2What database migration constraints does blue-green impose?
  3. 3How do you roll back after the switch?
  4. 4Why can long-lived connections complicate the cutover?

Say it in the interview

I run blue and green side by side, deploy and verify green, then change the upstream include atomically, run nginx -t and reload. Existing requests finish on old workers while new traffic goes to green. I keep blue alive for rollback and require backward-compatible database migrations. Long-lived connections need draining at the load balancer and a worker shutdown timeout so the old pool finishes cleanly.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Nginx mock interview and get scored feedback on depth, clarity and confidence.