Akuity, the company founded by the creators of Argo CD and Kargo, has added Fleet Management to Kargo Enterprise. The feature is in private beta. It lets platform teams release changes across hundreds of Kubernetes clusters, GPU nodes, and edge devices as one rollout. Each rollout is gated, verified, and reversible. Teams group clusters into a fleet and set the rollout order and failure threshold once. Kargo then moves each change through the fleet in waves, from pilot to canary to the general population, with a health check between each wave. A rollout stops only when the failure rate crosses the threshold, so one failed cluster does not halt the fleet. "Companies now run fleets of clusters, and the release process has become what limits how fast they can ship," said Hong Wang, co-founder and chief executive officer of Akuity.

Announcing Fleet Management for Kargo Enterprise: one release, hundreds of targets. October 12, 2026 Today, Akuity Inc. is announcing Fleet Management for Kargo Enterprise, which promotes a single change across hundreds or thousands of deployment targets in one coordinated rollout. Fleet Management brings rollout ordering, per-target verification, configurable failure thresholds, and aggregate visibility into the Kargo promotion workflow. Platform teams define how a change moves across the fleet, verify progress at each step, and control how far a rollout proceeds when problems appear. Tl;dr. * Fleet Management for Kargo Enterprise coordinates one release across hundreds or thousands of targets. * Ordered waves, per-target verification, and failure thresholds control how a change advances through the fleet. * Shared rollout visibility and inventory-driven membership cut manual orchestration as the fleet grows. * Fleet Management applies to existing Kargo Custom Steps, extending coordinated rollouts beyond Kubernetes. * Get started: The Fleet Management closed beta is open to teams looking to coordinate releases across hundreds or thousands of targets. For teams operating large Kubernetes estates, the challenge is familiar: a change that is ready for production still has to reach each target safely, and that step often runs on scripts and runbooks. As earlier posts in this series covered, the fleet is now the unit of operations, and promotion is where existing tooling falls short. Why Kubernetes fleet rollouts need dedicated controls. A platform engineer needs to patch cert-manager across 200 Kubernetes clusters. Updating the version in Git is straightforward. Delivering the patch safely requires more decisions. Which clusters should receive it first? What should the team check before the next group starts? If one cluster fails, should the entire rollout stop? How does the team distinguish an isolated infrastructure problem from a problem with the update itself? Those decisions often live outside the promotion workflow. Teams encode rollout order in CI scripts, maintain target lists in pipeline configuration, and use runbooks to coordinate batches. Engineers check individual environments and decide when it is safe to continue. Bringing that coordination into Kargo today means choosing between two models, and each has a cost. Modeling each application on each cluster as a separate Stage, Kargo's unit for a promotion target, preserves individual status but multiplies the work. With 100 applications across 200 clusters, that model creates 20,000 Stages to configure, maintain, and observe. A release for one application spans 200 separate promotions, and the team has to track verification, investigate failures, and coordinate recovery across each of them. Figure 1. Stage sprawl when each application-cluster pair is modeled as a separate Stage. Counts are illustrative. Collapsing the targets into one broad promotion avoids that sprawl, but leaves the platform team writing custom logic for rollout order, per-target verification, and failure handling. Either way, the platform team maintains the orchestration around each release. Fleet Management makes that coordination a native part of Kargo Enterprise, so platform teams manage one shared rollout and still see the status of each target. How does Kargo Fleet Management work? Fleet Management extends Kargo's promotion model from environments to the many targets inside each environment. Kargo already coordinates how changes move through development, staging, and production, and Fleet Management adds the progression through customer-specific clusters, regional infrastructure, or thousands of store locations within one environment. Teams define that progression in one shared workflow. Fleet Management groups targets into waves, verifies each target, and checks results against the rollout policy before advancing. Each target keeps its own promotion and verification status, and the rollout has an overall outcome, so teams can see both whether an individual target received the change and whether the release across the fleet met the defined policy. In practice, that looks like: * Patching shared cluster add-ons. A platform team updates cert-manager across its cluster estate, starting with pilot clusters and expanding through defined waves as verification passes. The same policy carries over to the next update. * Releasing to dedicated customer environments. A SaaS provider running a cluster per enterprise customer rolls out by customer tier and tracks customer-specific failures within one rollout. * Updating infrastructure across retail locations. A retailer with a cluster in each store moves a release from test locations to higher-impact sites, with failure thresholds that account for stores losing connectivity. What are the key features of Kargo Fleet Management? Fleet Management covers the rollout lifecycle for a release headed to many targets: how it progresses, when it stops, how teams follow it, which targets it includes, and who approves it. Rollout control. Ordered waves. Teams start with a small group, verify the result, and expand. A cluster add-on update might move through: * A pilot group: a small set of clusters that surfaces problems early. * A canary group: a broader set representing more of the fleet's operating conditions. * The remaining targets: the larger population, reached once earlier waves pass the required checks. Wave order reflects the infrastructure and the consequences of a failure, such as customer tier for a SaaS provider, test stores before high-traffic locations for a retailer, or region and cluster configuration for a platform team. Per-target verification. Completing an update on a target does not confirm the updated component works. Fleet Management verifies each target and gates progression between waves, so results from one group decide whether the change reaches the next. Failure thresholds. At fleet scale, some failures are unrelated to the release, such as an unreachable cluster or a store that loses connectivity. Configurable thresholds let teams tolerate isolated failures within policy, keep each one visible, and stop progression when failures cross the threshold. Coordinated rollback. Teams can stop a rollout and roll back across the fleet, with a record of which targets received the change and which need recovery. Figure 2. Conceptual Fleet Management rollout: pilot and canary waves precede broader rollout, with verification and approval gates controlling progression. Rollback follows the configured policy. Group sizes are illustrative. Visibility. Aggregate fleet view. While a rollout is in progress, one view shows whether it is advancing, waiting on verification, or blocked, along with which targets have completed, are still progressing, or need attention. Platform engineers use it to investigate and decide next steps. Application engineers use it to see why a release hasn't reached a particular customer's cluster. Membership and governance. Inventory-driven membership. Fleet Management discovers and maintains targets from an existing source of truth, such as Argo CD or cloud infrastructure inventory. As customer environments, stores, and clusters come and go, rollouts stay current without a duplicate target list in each pipeline. Release-level governance. Kargo Enterprise 1.12 introduced promotion windows, approval steps, and custom audit events. Fleet Management applies those controls at the rollout level, so reviewers approve a change and its scope once, then trace where it landed, when, and how it was reviewed. Together, these capabilities let a fleet grow by hundreds of targets without a matching growth in release work. Extending Fleet Management beyond Kubernetes with Custom Steps. Fleet Management applies to Kargo Custom Steps, which package team-defined promotion logic in container images and run it alongside built-in steps. Custom Steps can call vendor tools, work with VMs or GPU nodes, and add infrastructure-specific checks to a promotion workflow. For a GPU driver update, Custom Steps can drain workloads, apply the update, reboot the node, and verify GPU health, with the team supplying the logic and integrations for its infrastructure. Fleet Management adds coordinated rollout to that logic. Ordered waves, per-target verification, failure thresholds, and the aggregate fleet view apply to the Custom Steps a team already runs in Kargo, so a GPU driver update can move across thousands of nodes with the same controls as a cluster add-on. What's next: Join the closed beta. Teams looking to coordinate releases across hundreds or thousands of targets can apply for the Fleet Management closed beta to use it ahead of general availability. Learn more about Fleet Management for Kargo Enterprise Also, join the live Fleet Management webinar with Jesse Suen, Akuity CTO and co-creator of Argo CD and Kargo. In this webinar, Jesse will cover how to coordinate releases across a fleet, verify each wave, and keep rollout progress visible. Register here for the live session on Tuesday, October 27th @ 9:00 AM PT | 12 PM ET