Before solving the problem, let’s understand why it exists in the first place.

The simplest possible way to deploy a new version of an application is to stop the old container, and then start a new one running the updated image. This is easy to understand and reason about, but it has an obvious, unavoidable consequence: for the period between stopping the old container and the new one becoming genuinely ready to handle requests, there’s simply nothing available to serve incoming traffic at all. Anyone trying to reach the application during that gap experiences a failure.

A single, simple reordering that underlies nearly every zero-downtime approach.

Almost every genuine zero-downtime strategy shares the same fundamental reordering: instead of stopping the old version and then starting the new one, a new version is started first, confirmed to be genuinely working, and only then is the old version actually removed. For at least some period during the transition, both the old and new versions exist and run simultaneously, ensuring there’s never a moment where neither is available.

flowchart LR
    A["Old Version Running"] --> B["New Version Started Alongside It"]
    B --> C["New Version Confirmed Ready"]
    C --> D["Old Version Removed"]
    D --> E["New Version Running Alone"]
    style B fill:#fafafa,stroke:#171717
    style E fill:#fef2f2,stroke:#dc2626
        

Every specific technique discussed in the rest of this guide — rolling updates, blue-green deployments, canary releases — is, at its heart, a particular way of implementing this exact same core principle, differing mainly in how gradually the transition happens and how much risk is taken on at once.

The core principle from Chapter 2 depends entirely on genuinely knowing when the new version is actually ready.

As discussed elsewhere in the context of container states, a health check is a repeated test confirming whether an application is genuinely working correctly, not merely alive. In a zero-downtime deployment, this becomes the critical gate: the old version isn’t removed, and traffic isn’t shifted, until the new version’s health check reports genuinely healthy — not merely started, as explored in the context of service dependencies, but actually, verifiably ready to handle real traffic.

The most common approach, particularly for a service running as several identical containers at once.

As discussed in the context of defining services, a single service is often scaled to run as multiple identical containers simultaneously. A rolling update takes advantage of this directly: rather than replacing every container at once, it replaces them a few at a time, waiting for each new instance to become genuinely healthy before moving on to the next batch, keeping the majority of instances continuously available to handle traffic throughout the entire process.

sequenceDiagram
    participant Old as Old Instances
    participant New as New Instances

    Note over Old: Five instances running, serving traffic
    New->>New: One new instance started
    New->>New: Confirmed healthy
    Old->>Old: One old instance removed
    Note over Old,New: Repeat gradually, batch by batch
    Note over New: Eventually, all instances are the new version
        

This approach’s main strength is that it never requires doubling the total resources needed all at once, since only a small batch of extra instances exists at any given moment — a meaningful practical advantage over the approach discussed next in Chapter 5.

A different, more dramatic way of applying the same core principle from Chapter 2.

A blue-green deployment maintains two complete, entirely separate environments — conventionally labeled “blue” and “green” — with only one of them actively receiving real traffic at any given time. A new version is deployed entirely into the currently inactive environment, thoroughly verified there while completely isolated from real traffic, and only once it’s confirmed genuinely ready is traffic switched over to it all at once, instantly making it the new active environment.

Blue-green deployment’s biggest advantage is an extremely fast, simple rollback — since the previous environment is left completely intact and untouched, reverting is as immediate as switching traffic back to it. Its main trade-off is requiring enough resources to run two complete environments simultaneously, even if only briefly.

A more cautious approach, deliberately limiting exposure to a new version before fully committing.

A canary deployment takes a more gradual, cautious approach still: a new version is deployed alongside the old one, but initially receives only a small fraction of real, genuine traffic, rather than none at all (as with blue-green, before the switch) or a rapidly increasing share (as with a rolling update). If that small slice of real traffic reveals no problems, the share directed to the new version is gradually increased over time until it eventually handles all traffic.

The name comes from the historical practice of using canaries to detect danger in coal mines before it affected the miners themselves — a canary deployment similarly exposes a new version to real risk in a deliberately limited, controlled way, specifically to detect problems before they affect everyone.

Bringing up a new instance carefully is only half the picture — the old instance needs to leave carefully too.

As discussed elsewhere regarding stopping and starting containers, a graceful shutdown gives a process the opportunity to finish its current work cleanly before actually terminating. In a zero-downtime deployment, this matters enormously for the old instances being removed: a request already in progress when an old instance is told to shut down should ideally be allowed to finish, rather than being abruptly cut off mid-response, simply because the deployment happened to be in progress at that exact moment.

A refinement that works hand in hand with graceful shutdown.

Connection draining goes a step further than simply allowing an in-progress request to finish: before an old instance is even told to shut down, it’s first removed from receiving any new incoming traffic at all, while still being allowed to finish whatever requests it’s already handling. Only once it has genuinely finished all its existing work does it actually get stopped, ensuring no new request is ever sent to an instance that’s about to disappear.

flowchart TD
    A["Old Instance Marked for Removal"] --> B["Removed From New Traffic"]
    B --> C["Existing Requests Allowed to Finish"]
    C --> D["Instance Stopped, Once Fully Drained"]
    style D fill:#fef2f2,stroke:#dc2626
        

Without connection draining, there’s a genuine risk of a brand-new request being sent to an instance that’s already in the middle of shutting down, resulting in a failure that a well-drained deployment would have avoided entirely.

A genuinely harder challenge that most of the strategies above don’t automatically solve on their own.

If a new version of an application also requires a change to its database’s structure, a subtle but serious problem appears: during the transition period described in Chapter 2, both the old and new versions of the application are running simultaneously against the exact same, shared database. If the new database structure isn’t compatible with the old version of the application code still running alongside it, the deployment can fail in confusing, data-related ways, even if every other part of the deployment strategy is executed perfectly.

Why zero-downtime deployment is meaningfully easier for some kinds of services than others.

A stateless service — one that doesn’t hold any important data of its own beyond a single request — can generally be replaced freely, since any individual instance is entirely interchangeable with any other. A stateful service, such as a database, holds genuinely important data specific to that particular running instance, which makes simply replacing it with a fresh instance meaningfully more complicated, since the new instance doesn’t automatically inherit that existing state.

Most of the strategies discussed throughout this guide are best suited, directly and cleanly, to stateless services; genuinely stateful services, particularly databases, generally require their own dedicated, more specialized approaches to updating safely without downtime.

A genuine zero-downtime strategy needs to handle going backward just as carefully as going forward.

If a newly deployed version turns out to have a genuine problem, reversing the deployment needs to be just as careful and considered as the original rollout — an abrupt, careless rollback can introduce its own downtime, defeating the entire purpose of the careful original deployment. The same core principle from Chapter 2 applies equally in reverse: bring the old, known-good version back and confirm it’s healthy before removing the problematic new version, rather than the other way around.

Watching what’s actually happening while a transition like this is underway.

During any of the deployment strategies discussed above, actively watching relevant metrics — error rates, response times, resource usage, as discussed elsewhere regarding container metrics — provides an essential, real-time signal for whether the new version is genuinely behaving well, well before a full rollout completes. This is particularly critical for the canary approach from Chapter 6, where the entire strategy depends specifically on carefully observing a small, initial slice of real traffic before expanding further.

A short checklist for genuinely achieving zero downtime, rather than merely aiming for it.

Zero-downtime deployment is a standard, expected practice across any organization running a genuinely continuously available service.

As explained in Chapter 1, there’s an unavoidable gap between the old version stopping and the new one becoming genuinely ready, during which nothing is available to handle requests.

As covered in Chapter 2, starting the new version first, confirming it’s genuinely ready, and only then removing the old one — never the reverse order.

As explained in Chapters 4 and 5, a rolling update replaces instances gradually with modest extra resource needs, while blue-green switches all traffic at once between two complete, parallel environments.

As discussed in Chapter 6, it deliberately limits a new version to a small slice of real traffic initially, catching problems before they affect the entire user base.

As explained in Chapter 9, both the old and new application versions run against the same database simultaneously during the transition, requiring changes compatible with both at once.

No — as covered in Chapter 10, stateless services fit these strategies naturally, while genuinely stateful services like databases require their own, more specialized approaches.

Zero-downtime deployment is fundamentally about reordering a simple, obvious default — stop the old version, then start the new one — into something more deliberate: start the new version, genuinely confirm it’s ready, and only then remove the old one. Every specific technique explored here, from gradual rolling updates to instant blue-green switches to cautious canary releases, applies that same core principle in a different way. Real, robust zero-downtime deployment also depends on graceful shutdown and connection draining to protect existing requests, careful handling of database schema changes during the transition window, and monitoring and rollback plans treated with the same seriousness as the deployment itself. Done well, users never notice a deployment happened at all — which is precisely the point.