Connect with us

NEWS

CIQ Bets Fuzzball Can Own the Multi-Cloud GPU Queue

CIQ expanded Fuzzball across five clouds and on-prem, betting one Rocky Linux workflow file can outrun cloud and GPU lock-in.

Published

on

June 4, 2026, CIQ opened Fuzzball to CoreWeave, AWS, Google Cloud, Oracle Cloud, and Microsoft Azure, so one workflow file can run on any of them. The same file still runs on Warewulf, VMware, or bare metal. Fuzzball then sends each job by cost, performance, and where the data already lives.

That launch is a bet from Gregory Kurtzer, chief executive and founder of CIQ. He is wagering that a Rocky Linux workflow file can be the production queue for AI and HPC, while hyperscalers and GPU vendors keep fighting over the metal underneath.

Five Clouds Share One Workflow File

CIQ, the company behind Rocky Linux, described full multi-cloud Fuzzball support as a way to stop rebuilding pipelines every time a team adds a cloud. The file lists compute jobs, data movement, container images, and resource needs. It carries no cloud-specific logic. An orchestration layer turns that file into whatever sits underneath.

The launch example is blunt. A genomics team that checks a sequencing pipeline on AWS moves it to Azure or Oracle Cloud without editing the definition. A training job that needs dense H100 GPUs goes to CoreWeave. A data-sensitive simulation stays on premises under policy. Container images, data movement, and job order stay the same.

Fuzzball Federate is the broker across those clusters. It looks at the live set of environments and picks a destination at runtime. Customers do not keep a separate toolchain, deploy script, or IAM model for each provider, CIQ said.

https://x.com/CtrlIQ/status/2062569674127127019

The public cloud list is five names, not a vague “hybrid” slide. On-prem remains a first-class target beside them, which is the part most cloud-native GPU routers treat as an afterthought.

WHERE FUZZBALL CAN LAND A JOB

Destination What CIQ says it is for How identity is handled
CoreWeave Dense GPU work such as H100 training Orchestrate runs in CoreWeave Kubernetes
AWS Hyperscale capacity and burst IAM Roles
Google Cloud Hyperscale capacity Workload Identity
Oracle Cloud Hyperscale capacity Dynamic Groups
Microsoft Azure Hyperscale capacity on AKS Managed Identities
On-premises Sovereign or data-local work Warewulf, VMware, or bare metal

Teams that want a starting point rather than a blank YAML file can pull official Fuzzball workflow templates from CIQ’s catalog repo. Stable clusters pin to a versioned branch. Unstable clusters follow main.

What a Single Azure Deploy Command Builds

Azure is the newest hyperscaler target in that set, and it is a destination, not the product. Chris Wolford, director of engineering at CIQ, wrote on June 2, 2026, that a chemist can move a GROMACS run from AWS to Azure without touching the workflow. Users describe needs in plain terms, such as 4 CPUs, 16 GB of memory, and one NVIDIA GPU. They do not pick regions, VM SKUs, or storage backends.

Standing the cluster up is a CLI call, fuzzball cluster azure deploy. Wolford walked through the two-phase Azure cluster deploy that follows, with no trip through the Azure portal.

THE TWO-PHASE AZURE STAND-UP

  • Phase 1, bootstrap: The CLI submits an ARM template that creates a resource group, Managed Identities for a Pulumi runner, a Storage Account and blob container for state, Key Vault for secret encryption, and an Azure Functions handler.
  • Phase 2, the cluster: That handler runs Pulumi to build a private regional AKS cluster with Workload Identity and per-pool autoscaling, PostgreSQL Flexible Server, Azure Files Premium NFS over a private endpoint, DNS, CDN, Log Analytics, a VNet with private subnets, and the Fuzzball operator via Helm.
  • Where work runs: Standard jobs land on Standard_D and Standard_E VMs. GPU jobs use Standard_NC, Standard_ND, or Standard_NV VMs. Substrate nodes, the machines that execute containers, boot a Rocky Linux 9 image.

That Azure path is the same idea CIQ uses on AWS, Google Cloud, and Oracle Cloud: shared operator and observability pieces, local cloud resources underneath. For readers who want the Microsoft-specific walk-through of Azure joining Fuzzball’s five-cloud layer, the AKS stack is the concrete artifact. The control plane still sits above it.

One IAM Model for Five Providers

Bjorn Hovland, president of CIQ, put the operational complaint in one line. “Fuzzball turns multi-cloud from a liability into a competitive advantage,” he said. “Five clouds used to mean five IAM models, five deployment pipelines, and five sets of operational overhead with complexity and risk being multiplied.”

The June release answers that with one IAM model, one set of role-based access policies, and one secrets posture across every cloud it runs on. Static keys are out. The platform uses Workload Identity on Google Cloud, Managed Identities on Azure, Dynamic Groups on Oracle Cloud, and IAM Roles on AWS. CIQ’s line is that security travels with the workflow, not with the cloud.

On Azure, Managed Identities and Federated Identity Credentials map AKS workloads to Azure RBAC roles for provision, secret, and billing identities. Secrets and encryption keys live in Key Vault. The AKS cluster uses private nodes and NAT for outbound traffic. Fuzzball still applies its own RBAC for who can submit jobs, touch data, and manage clusters, on top of those cloud primitives.

AI teams today are asked to ship faster, control costs, and maintain sovereignty over their data, simultaneously, across infrastructure that was never designed to work together. We built Fuzzball to solve that problem at the architectural level. When your workflow definition abstracts its requirements properly, you get portable access to every GPU environment the market offers and the freedom to route to wherever the best price, performance, and data policy lives. Controlling your infrastructure and workloads is what enterprise AI infrastructure requires for production, and no other platform delivers it.

Gregory Kurtzer, CEO and founder of CIQ, June 4, 2026 press release

That last clause is the wager, stated as fact. Other queues already exist. The question is which buyer believes it.

Kurtzer Has Rebuilt This Layer Before

The bet makes more sense if you follow the stack he keeps rebuilding. In the early 2000s at Lawrence Berkeley National Laboratory, Kurtzer wrote Warewulf to provision HPC clusters that scientists were otherwise taping together. He co-created CentOS, the free Enterprise Linux rebuild that filled data centers for years. When Docker-style containers clashed with HPC security and performance, he built Singularity, later Apptainer.

He founded CIQ in April 2020 to turn that line of work into a cloud-native platform for performance-heavy jobs. Fuzzball was the intended orchestrator, described internally as the Kubernetes of high-performance computing. Eight months in, Red Hat said CentOS would stop being a stable downstream rebuild. Kurtzer posted to a public forum: “I’m Greg, I’m one of the original founders of CentOS, and I’m going to recreate this. Join me.”

Six weeks later, more than 10,000 people had joined. The project became Rocky Linux, named for Rocky McGaugh, a late CentOS co-founder. It shipped seven months after the announcement. CIQ now says Rocky Linux runs on 2.75 million actively deployed instances, measured by EPEL telemetry, and claims 90% of Fortune 100 companies use CIQ-supported technologies. Those are CIQ’s figures.

FROM BERKELEY LAB TO A FIVE-CLOUD QUEUE

  1. Early 2000s: Kurtzer builds Warewulf for cluster provisioning at Berkeley Lab and co-creates CentOS.
  2. Mid-2010s: Singularity ships as an HPC container runtime after Docker-style tools fail lab security models.
  3. April 2020: CIQ is founded; Fuzzball is the planned orchestrator for hybrid performance work.
  4. December 2020: CentOS changes course; Kurtzer starts Rocky Linux, which ships seven months later.
  5. May 18, 2023: CIQ launches Fuzzball as a container-first platform for HPC and AI workflows.
  6. January 30, 2026: CoreWeave becomes the first neo-cloud Fuzzball can provision, still in preview.
  7. June 4, 2026: Full multi-cloud support ships across five public clouds plus on-prem.
  8. September 3, 2026: Fuzzball 4.2 adds agents, AMD GPUs, and health-aware scheduling.

Microsoft already treats CIQ as the endorsed Rocky Linux publisher on Azure. Community Rocky images still come from the Rocky Enterprise Software Foundation, but they sit outside the endorsed program. CIQ’s marketplace images add Azure-tuned kernels and pre-integrated NVIDIA and AMD GPU drivers, which is why those Substrate nodes can boot Rocky Linux 9 without a side quest for drivers.

The GPU Shortage That Made Five Clouds Normal

CIQ did not invent multi-cloud. Teams already chase scarce GPUs, compare prices, and keep some jobs in a given country or a basement cluster. The tax is the rebuild: new scripts, new identity, new tests, then the same science again. Hovland called that overhead the thing blocking wider multi-cloud use.

Open-source tools such as SkyPilot already send training jobs toward cheaper GPU capacity across clouds, which is the obvious counter to CIQ’s “no other platform” line. SkyPilot is a strong fit for burst training and price shopping. It is a weaker fit for a lab that still submits to Slurm or PBS, provisions with Warewulf, and needs one secrets model that follows the job from a basement cluster to Azure.

That lab buyer got a sharper reason to care in December 2025, when NVIDIA bought SchedMD, the company behind Slurm. CIQ’s response was to keep Slurm and PBS as backends rather than replace them. Users can keep submitting the way they always have, then adopt container workflows and cloud burst when they want. Fuzzball 4.2 later spelled out the same independence on the GPU side: buy NVIDIA or AMD without changing how the queue is operated.

So the five-cloud launch is less a feature list than a claim about who owns the next layer. If Azure Machine Learning or SageMaker is the system of record, Fuzzball is extra. If the workflow file is the system of record, Azure is a place jobs land when the policy and the price say so.

Fuzzball 4.2 Lets Agents Submit the Next Job

On September 3, 2026, CIQ shipped Fuzzball 4.2 on the same five clouds and the same on-prem targets. The release does not add a sixth provider. It tightens the bet: the queue should run training, inference, and now agents, on hardware the customer already governs.

WHAT SHIPPED IN FUZZBALL 4.2

  • MCP server: Agents can inspect a Fuzzball environment and draft, submit, and monitor workflows. Writes, execution, and destructive actions need explicit operator permission.
  • Workflows calling workflows: Each job and service container gets a scoped API credential and the cluster API address, so running work can submit, track, and stop more work without shared secrets.
  • Health-aware scheduling: Hosts and GPUs get a reliability score. Jobs restart elsewhere on a fault. Degraded nodes are cordoned, drained, and replaced.
  • AMD ROCm: The scheduler can discover and place work on NVIDIA and AMD GPUs. CIQ and AMD had already announced AMD-optimized Rocky Linux images in March 2026.

4.2 also adds first-pass per-workflow accounting for compute, storage, and network egress, plus organization-level storage isolation and compute-policy grants so more than one team can share a GPU pool. Workloads still run unprivileged and rootless, a habit Fuzzball inherited from HPC systems that already had thousands of users on one cluster.

Enterprises have moved their AI in-house faster than they have built the operations to run it. What decides whether that works is the software layer above the hardware, and Fuzzball 4.2 is that layer. Teams build, train, and serve on one platform, on infrastructure the organization governs, with their models and their data staying where they belong.

Gregory Kurtzer, CEO and founder of CIQ, Fuzzball 4.2 announcement

CIQ will show that stack live on September 17, 2026, at 11 AM PT / 2 PM ET: an agent driving Fuzzball over MCP, workflows launching follow-on work, and the scheduler routing around a failing node.

On Warewulf, VMware, and Bare Metal

The June launch kept repeating a detail cloud pitches usually bury. On-prem is not a compatibility checkbox. Warewulf, VMware, and bare metal remain valid places for the same file. Fuzzball Orchestrate is a Kubernetes application. Fuzzball Substrate, the execution agent, runs outside Kubernetes so jobs can reach the hardware. Substrate installs as an RPM on Enterprise Linux and can be baked into a Warewulf node image.

That is the buyer CIQ actually knows: national labs, research computing groups, and AI teams that already own GPUs and do not want a second identity system to use them after hours. CoreWeave is in the matrix because H100 density is there. Azure is in the matrix because many of those same teams already have an Azure subscription and an endorsed Rocky image. The file is supposed to treat those as peers.

Whether the bet pays is still open. SkyPilot will keep winning teams that only want a cheaper GPU hour. Hyperscaler ML platforms will keep winning teams that never leave one cloud. GPU vendors will keep buying pieces of the scheduler stack. Fuzzball’s counter is a YAML file that already runs on the cluster in the basement, and now on five public clouds, without a rewrite. On September 17, CIQ has to show an agent using that file while a node fails and the job simply continues somewhere else.

Harry edits WinAddons, an independent news site that he owns and runs, covering Windows, Xbox, Azure, Microsoft 365, Teams, OneDrive, Outlook, the software built around them and Microsoft's business. His method comes from ten years in journalism, a reporter's years followed by an editor's, and the bulk of that decade has been spent watching Microsoft ship. His reporting starts with what Microsoft publishes: release notes and KB articles read in full, build numbers checked on an installed machine, MSRC advisories and the CVE records behind them, the Azure status history, lifecycle pages, store listings in the market they apply to, and the earnings releases and filings that carry the company's numbers. Every figure is checked against its source before publication, and a public corrections policy explains how mistakes are fixed and labelled. On security stories he does not publish exploit details before a fix is available, reporting what is affected and what to do instead. Pre-release features are labelled by channel and build, and a rumour is called a rumour. Readers can reach Harry at support@winaddons.com.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Trending