Replace Hosts or Roll Out in Rings? How Hydra and Atlas AVD Ship a New Golden Image

Every AVD team ships a new golden image at least once a month. Hydra moves hosts to a new image with a replace-hosts wizard that drains and swaps them. Atlas AVD rolls it out in rings, canary to full, gating each ring on health and user experience and rolling back on its own if a ring regresses. Here is how each works, and why the second approach is safer at scale.

By David,

Patch Tuesday lands. You update the golden image, capture a new version, and now it has to reach every session host without the help desk phones lighting up. How your platform does that last step decides whether a bad image is a footnote or an outage.

Hydra and Atlas AVD agree on most of the pipeline. They differ on the step that matters most: how the new version reaches users.

The short version: both platforms capture a golden image to Azure Compute Gallery and replace session hosts with the new version. Hydra does it with a replace-hosts wizard that drains hosts and swaps them to the new image. Atlas AVD rolls it out in staged rings, canary, pilot, broad, then full, with a bake period and a health and user experience gate before each promotion. If a ring regresses, Atlas halts the rollout and points that ring back at the previous version automatically. A bad image reaches a canary pool, not your whole estate.

Hydra capabilities are taken from its public documentation as of October 2026. Vendors change their products, so confirm current details directly.


1. What both platforms get right

Credit where it's due: the fundamentals are solid on both sides.

  • Capture to Azure Compute Gallery. Both capture a golden image and publish it as a versioned image in Azure Compute Gallery. Hydra's capture keeps the master VM intact; Atlas captures with automatic generalization.
  • Drain before replace. Neither platform yanks a host out from under signed-in users. Hosts are put in drain mode so new sessions land elsewhere while existing users finish.
  • Versioned images. A numbered version in the gallery is what makes rollback possible at all. Our golden image management guide covers versioning and replication in depth.

The difference starts once the new version exists.


2. The replace-hosts approach

Hydra's replace-hosts wizard is a clear, guided way to move a host pool onto a new image: choose the pool and the image, and it drains the hosts and swaps them over.

That's a sensible model, and for one small pool it's often all you need. Its limit is that the unit of change is the host pool, and the replace-hosts workflow doesn't describe a health gate or an automatic rollback, so the check that the image is good falls to you. If the new image breaks a line-of-business app, slows logons because of a profile change, or fails a driver on one VM size, you find out when users in that pool do. Then you run the wizard again, back to the old version.

At ten pools that's an uncomfortable afternoon. At fifty pools across a dozen customer tenants, it's a pattern you want a platform to handle for you.


3. The staged-ring approach

Atlas AVD treats a new image as a rollout, not an action. You define rings of host pools, in order:

  1. Canary: one low-risk pool, often IT's own or a small volunteer group.
  2. Pilot: a slice of real users across departments.
  3. Broad: most production pools.
  4. Full: everything else, including the pools you're most careful with.

Atlas pins the canary ring's pools to the new version, and the existing reimage engine moves their hosts onto it, draining first. Then it waits for a bake period, so the image runs through real logons and real workloads. Before promoting to the next ring, it checks a health and user experience score for the ring's pools. If the score holds, the next ring starts. If it drops, Atlas halts the rollout and points the ring back at the previous version, and the reimage engine moves the hosts back.

Two safeguards keep this from going wrong in quieter ways:

  • Only matching pools are touched. A pool joins a rollout only if it uses the same image definition, so a misconfigured ring can't repoint an unrelated pool.
  • The version must be deployable. Atlas checks that the target version is actually available before pinning a ring to it, so a ring is never pointed at a version that's missing or still being created.

The result is that a bad image costs you one canary pool's worth of disruption, measured and reversed automatically, instead of a host pool's worth found by your users.


4. Capacity during the swap

There's a second, quieter risk in any image update: capacity. Every host you drain is a host users can't land on, and in a busy pool, swapping hosts one by one can leave the morning logon wave short.

Atlas can build replacement hosts on the new image before retiring the old ones, so pool capacity doesn't dip during a rollout. Remember to budget Azure quota for that overlap. Adaptive Quota shows the vCores each VM family needs against your quota before a rollout fails on it, and our quota guide shows how to request more without leaving Atlas.


5. Side by side

Atlas AVDHydra
Image captureAutomatic generalization to Azure Compute GalleryKeeps the master VM intact, to Azure Compute Gallery
Drain before replaceYesYes
Unit of rolloutOrdered rings of host poolsA host pool, through the wizard
Bake period between stagesYesNot a documented capability
Health and user experience gateYes, before every promotionNot a documented capability
Automatic rollbackYes, the ring is pointed back at the previous versionNot a documented capability
Build replacements before retiring old hostsYesDrains and swaps hosts
Audit trail of every image changeYesNot a documented capability

6. Why this matters more every month

Image updates are the one change every AVD team makes on a schedule, forever. Monthly cumulative updates, Office channel updates, Teams, browser and line-of-business app updates all ride the image. Each one is a chance to break something.

A platform that treats each update as a guarded, measured, reversible rollout turns that monthly risk into routine. That's especially true for MSPs, where one bad image can reach every customer at once, and for regulated teams, where every image change also needs to appear in the audit trail with who approved it and when.


Try it on your own image

If you're managing images today with a replace-and-swap workflow, the quickest way to see the difference is to run one rollout through rings. Start an Atlas AVD trial, point a canary ring at a test pool, and watch the gate do its job. See the imaging feature page for the details, or compare everything else on Atlas AVD vs Hydra.