VergeOS adds CSI driver, Cloud Controller Manager, Cluster Autoscaler, and Rancher node driver — letting VMware shops running Kubernetes retire vSphere licensing, distribution licensing, and overlay storage in a single platform decision.
ANN ARBOR, Mich. — May 12, 2026 — VergeIO, the Private Cloud Operating System company, today announced general availability of Kubernetes support in VergeOS. The release adds a CSI storage driver, Cloud Controller Manager, Cluster Autoscaler, and Rancher node driver with UI extension, all distributed as Helm charts from the verge-io repository on GitHub. Together, the components let VMware customers running Kubernetes collapse three separate licensing taxes — vSphere, a Kubernetes distribution, and overlay storage — into a single platform.
VMware shops running Kubernetes today pay three separate vendors to do one job. They pay Broadcom for vSphere licensing to host cluster nodes. They pay a Kubernetes distribution tax — Tanzu, OpenShift, or Rancher Prime. Many pay a third tax for overlay storage like Longhorn or Portworx because vSphere storage policies do not extend cleanly into Kubernetes without commercial Tanzu add-ons. VergeOS now handles all three layers natively. Rancher remains the management plane customers already use. Workloads move on the customer’s timeline.
Support, Not a Distribution
VergeIO is not introducing a Kubernetes distribution. The support layer assumes customers already run a distribution they trust — RKE2, K3s, vanilla upstream, or a vendor distribution — and provides the platform underneath. Four components ship in this release:
- CSI Driver — delegates storage operations directly to the VergeOS API, so persistent volumes participate in the full VergeFS feature set including inline deduplication, multi-tier placement, and integrated snapshots.
- Cloud Controller Manager — integrates VergeOS VMs as first-class Kubernetes nodes, automatically populating provider IDs, instance metadata, and IP addresses, with native VNet-based LoadBalancer services on the near term roadmap.
- Rancher Node Driver — provisions, manages, and autoscales Kubernetes clusters on VergeOS through Rancher. The Docker Machine driver clones VM templates, injects SSH keys via cloud-init, configures CPU and memory, attaches networks, and powers on. Node pools scale up and down automatically based on pending pod resource requests, executed against VergeOS compute capacity.
- Rancher UI Extension — surfaces VergeOS-specific cloud credential and machine configuration forms inside the Rancher UI. Operators get the same provisioning experience for VergeOS clusters as for vSphere, with no context switch and no separate tool.
Customers shouldn’t have to rebuild their applications to leave VMware — and once they leave, they shouldn’t be locked in again. With Rancher on VergeOS, the workloads move, and they stay portable.
Validated in Production
NGAMING, the group that brings together Türkiye’s leading brands in the digital entertainment and gaming sector — including NESINE, Atyarisi.com, and Liderform — served as the design partner during the development process. The Nesine engineering team worked in close collaboration with VergeIO during the MVP phase to successfully validate the CSI Driver, Cloud Controller Manager, and Rancher Node Driver against real production workloads. Nesine has approved the Kubernetes support layer for use in its production environment.
Three Customer Situations
Kubernetes support in VergeOS addresses three distinct VMware-customer situations.
Rancher Inside vSphere
Customers running Rancher to manage Kubernetes clusters inside vSphere can keep their Rancher control plane unchanged and replace the substrate underneath. Application teams see no change in their day-to-day Kubernetes operations. Platform teams see the vSphere renewal disappear.
Tanzu Kubernetes Grid Customers
Customers running Tanzu Kubernetes Grid facing Broadcom roadmap uncertainty and bundled licensing pressure can run new clusters on VergeOS while existing TKG clusters continue to operate. Rancher manages both for the duration of the migration. Workloads move on the customer’s timeline — stateless services first, stateful workloads after the new platform validates under real load.
Bare-Metal Kubernetes
Customers running Kubernetes directly on bare metal can add hypervisor benefits — live migration, integrated DR, and a shared snapshot model — without changing their Kubernetes operations workflow. RKE2 and K3s clusters provisioned on VergeOS gain VM-level isolation and unified storage policy across containerized and traditional workloads.
Go Deeper
The full architectural argument, technical overview, live demonstration, and complete research collection live behind four destinations:
Availability
Generally Available Now
All four components are generally available now and downloadable as Helm charts from the verge-io repository on GitHub.
About VergeIO
VergeIO is the Private Cloud Operating System company, headquartered in Ann Arbor, Michigan. Its platform, VergeOS, collapses virtualization, storage, networking, and data protection into a single integrated software stack running on commodity hardware. VergeOS is a leading VMware alternative, recognized by DCIG as a Top 5 VMware Alternative across both the SME and SLED categories. The company has grown annual recurring revenue more than 80 percent year over year and serves enterprise, public sector, and service provider customers worldwide. Learn more at www.verge.io.
Media Contact
Judy Smith
JPR Communications for VergeIO
[email protected]
818-522-9673
VergeOS exposes the seven primary SMART attributes on every drive in the cluster in real time: total writes, power-on hours, reallocated sectors, wear leveling count, ECC errors, end-to-end errors, and temperature. The exposure is continuous, not on-demand. A drive that arrives reporting twenty percent used wear gets watched against its reported state from the moment it joins the pool. Tampered drives reveal themselves quickly when actual write activity moves the counters faster than the reported state would predict. VergeOS alerting can be setup to warn you of signs of this behavior without you having to check in on every drive every day.
The platform handles correlated batch failure on three levels. The rate-of-change SMART subscription fires when multiple drives in a batch show wear advancing in synchronized patterns, giving the IT operator days or weeks of warning. RF2 (two synchronous replicas) absorbs the loss of any one drive without service degradation. RF3 (three synchronous replicas) absorbs two. The choice between RF2 and RF3 is a capacity question, and most customers run RF2 once they understand the layer above it.
Your 2026 SAN refresh is in trouble. Flash inflation has pushed enterprise SSD prices up 70 percent. Refresh budgets locked in 2024 are now under-funded against current list pricing. The standard responses are to defer expansion, cut scope, or absorb the cost as a budget overrun. None of those options preserve the operational plan you set last year.
Most infrastructure teams treat their SAN refresh and their hypervisor strategy as separate problems. The SAN refresh is a procurement decision, owned by storage architects. The VMware exit is a platform decision, owned by virtualization leads and the CIO. The two budgets land in different fiscal lines, the two evaluation cycles run on different clocks, and the two vendor conversations rarely overlap.
Gartner’s planning data projects that 55 percent of enterprises will be in proof-of-concept evaluations of VMware alternatives by 2028. Industry reporting on VMware price increases under Broadcom shows a range from 50 percent to over 1,000 percent for affected customers. CloudBolt’s 2024 survey found 99 percent of IT decision-makers reporting concern about the acquisition’s impact. These three numbers explain why the migration question is no longer optional for most VMware shops. They do not explain why the backup tier needs to be redesigned alongside it.
Single-product VMware exit data protection fails one of two tests. Infrastructure-only protection lives inside the virtualization platform. It handles hardware failures and operational continuity well, but offers no compliance retention, no air-gapped immutability, and limited defense against ransomware targeting the production cluster itself. Backup-only protection can take minutes to hours to recover after a hardware event and depends entirely on backup scheduling for meaningful protection.
The numbers point to a single architectural answer. A backup that lives in the same trust domain as production has been compromised by definition once an attacker reaches the production system. Immutability has to exist at both layers. ioClone snapshots inside VergeOS are read-only by default and can be set to immutable by checking a box. As a result, they cannot be modified by an attacker who reaches the production cluster. Storware adds immutable storage targets, such as S3 Object Lock and Data Domain Retention Lock, outside the cluster trust domain. Recovery from in-cluster snapshots is near-instant. Recovery from the Storware tier is slower but provides the long-term retention horizon for compliance and forensic analysis.
Before addressing what organizations should do, it is worth being direct about what they should not do. Rising all-flash array cost in 2026 does not make hard drives a compelling alternative. HDDs fail unpredictably, carry latency profiles that disqualify them from most production workloads, and the operational complexity of managing a tiered architecture dependent on spinning media eliminates whatever savings the lower media cost implies. There is a reason IT moved to all-flash in the first place. The goal is not to abandon flash — it is to consume flash more affordably. Three architectural decisions determine whether that is possible.
VergeOS takes a fundamentally different approach. Deduplication is not a feature that runs on stored data after the fact. It is built directly into the VergeOS operating system and runs permanently across the entire environment — cache, network, RAM, and storage — as a core function. A single copy of any block exists in the cluster regardless of how many virtual machines reference it, and that deduplication applies from the moment data is written rather than as a background cleanup pass.
Everpure’s FlashArray and FlashBlade platforms accept only DirectFlash Modules — a proprietary media format that Everpure itself manufactures. Customers cannot source capacity from any other vendor. When component costs surge 300 to 900 percent, a storage platform that accepts media from only one manufacturer has no alternative sourcing path and no way to manage all-flash array cost exposure. The closed architecture that delivered engineering elegance in a declining-price market becomes a one-way pricing funnel when supply inverts.
That plan made sense in 2024. The renewal was expensive but predictable — Broadcom had only completed the acquisition a year earlier, many organizations still had time remaining on existing contracts, and buying one more year to evaluate alternatives was a reasonable call. The servers were a known quantity. The budget math was uncomfortable but manageable. What changed is not the plan — it is the price of executing it. The two line items that seemed controllable have both moved against you at the same time, and the combined number no longer looks like buying time. It looks like paying a premium to stay on a platform you have already decided to leave.
The server market shifted in late 2024 and has not corrected. DRAM contract prices rose 58–63% quarter over quarter in the first half of 2026, driven by AI infrastructure buildout at the hyperscaler level that locked up supply before enterprise buyers could compete. This cycle has been characterized as a 
VergeOS changes the math at every layer where the conventional path breaks down. The starting point is hardware: VergeOS installs on any x86 server already in the data center. The servers the organization was planning to buy are no longer required. The $40,000 nodes, the three-to-six-month lead times, the OEM quote that expires before the purchase order clears — none of that applies. The migration starts on the day the organization decides to move, on hardware already powered on and already running workloads.