The most surprising thing about deploying with zero downtime using slot swaps is that the application often runs on both the old and new versions simultaneously, and the switch is nearly instantaneous.
Let’s see this in action. Imagine you have a web application running on a production server (let’s call it prod-01). You’re about to deploy a new version. Instead of updating prod-01 directly, you provision a new server, prod-02, and deploy the new version of your application to it.
Here’s a simplified snapshot of what your load balancer configuration might look like before the swap:
upstream app_servers {
server prod-01:8080 weight=100;
server prod-02:8080 weight=0; # New version, but not receiving traffic
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://app_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_set_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In this setup, prod-01 is actively serving all traffic (weight=100), while prod-02 is ready but has a weight=0, meaning it gets no traffic.
Now, you’ve thoroughly tested prod-02 (perhaps with synthetic traffic or a canary release). It’s time to make the swap. This is where the magic happens. You don’t touch prod-01 at all. Instead, you modify the load balancer configuration to reverse the weights:
upstream app_servers {
server prod-01:8080 weight=0; # Old version, now gets no traffic
server prod-02:8080 weight=100; # New version, now serves all traffic
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://app_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_set_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
You reload the Nginx configuration (e.g., sudo nginx -s reload). The load balancer, upon receiving new incoming connections or requests, will now direct them exclusively to prod-02. Existing connections to prod-01 will continue to be served by prod-01 until they naturally complete or time out. This transition is typically so fast that users experience no interruption.
This pattern, known as a "blue-green deployment" or "red-black deployment," is the foundation for zero-downtime deployments. The core idea is maintaining two identical production environments, "blue" (current version) and "green" (new version). Traffic is routed to one environment. When you want to deploy, you deploy the new version to the inactive environment, test it thoroughly, and then instantly switch traffic to it.
The "slot swap" is a more abstract concept often found in managed platform services (like Azure App Service Slots or Google App Engine Traffic Splitting). Instead of managing two distinct sets of servers yourself, the platform provides you with "slots." You deploy your new version to a staging slot, test it, and then initiate a "swap" operation. The platform handles the underlying traffic redirection, often at the network level, between the slots. The key benefit here is that the platform abstracts away the load balancer configuration and server provisioning.
The critical component that makes this work is a load balancer or traffic manager capable of dynamically changing backend weights or routing rules without dropping existing connections. For Nginx, this is handled by its ability to reload configuration safely. For cloud platforms, it’s their internal traffic management systems. The "swap" isn’t about moving code; it’s about moving network traffic.
One crucial aspect often overlooked is how to handle long-running requests or WebSocket connections during a swap. If a user has an active WebSocket connection to the "blue" environment and you swap traffic to "green," that connection will be abruptly terminated. To mitigate this, you might implement a grace period where the old environment continues to serve existing connections for a short while after the swap, or gracefully degrade the old environment by returning 503 Service Unavailable for new requests while allowing existing ones to finish.
After the swap, the old environment (prod-01 in our example) becomes your new staging environment, ready to receive the next deployment. This continuous cycle of deploy-to-staging, test, swap, and roll-back-to-staging is what enables truly seamless updates.
The next challenge you’ll encounter is managing database schema changes alongside these application deployments.