Customer story
A hyperscale GPU cloud provider keeps fleet automation moving with Ascender Pro
A $5B+ hyperscale GPU cloud provider runs its fleet automation, spanning thousands of AMD and NVIDIA nodes, on Ascender Pro and Ascender Ledger, replacing automation tooling that had stalled and left the team with no real-time visibility into fleet-wide change.
Thousands
GPU nodes
Across AMD and NVIDIA hardware
2.5M
Automation executions
Every month
<30
Minutes per site to migrate
20 to 30 minutes, a Helm image swap
180,000+
Nodes coming online
By the end of 2027
The fleet, the problem, and why Ascender Pro
How a hyperscale GPU cloud moved its node lifecycle automation onto Ascender Pro without rebuilding the workflow underneath it.
- Who
- A $5B+ hyperscale GPU cloud provider running AI infrastructure across thousands of AMD and NVIDIA nodes
- What they run
- Thousands of nodes across AMD and NVIDIA GPU workloads, 100% Kubernetes and Helm driven, with roughly 2.5 million automation executions a month
- What’s on it
- Ascender Pro and Ascender Ledger, zero-CVE containers, on a modernized Django 5 and Valkey stack
- What it supports
- Node lifecycle automation at hyperscale, including onboarding, firmware flashing, and diagnostics, across a fleet growing toward half a million nodes at full build-out
- Why Ascender Pro
- A drop-in migration onto the same execution model already in place, plus real-time compliance and change tracking the prior tooling couldn’t provide
The story in brief
The provider’s automation layer had been frozen for more than a year and a half, with an operational bug hurting stability and no real-time way to track change across a fast-growing fleet.
Ascender Pro dropped into the same mesh and instance-group model already running, so the migration was a 20 to 30 minute Helm image swap per site. Ascender Ledger closed the compliance gap with real-time change data and alert-driven playbooks.
Why this matters beyond one fleet
A migration that doesn’t mean a rebuild.
When automation tooling already runs on a mesh and instance-group model, moving to Ascender Pro is a Helm image swap, not a re-architecture of the workflow underneath it.
Compliance that scales with the fleet.
Real-time change diffs, package inventory, and per-host data mean audit demands don’t outgrow the tooling as the environment grows.
Bugs that get fixed, not worked around.
An operational defect already resolved upstream in Ascender Pro doesn’t need a custom fix on the customer’s end. It needs a migration.
Talk to CIQ about Ascender Pro
See how a hyperscale GPU cloud provider automates fleet operations on Ascender Pro and Ascender Ledger, and what a drop-in migration and real-time compliance tracking look like at that scale.