Broadcom Donates Velero to CNCF: A New Era for Kubernetes Backup and Migration

At KubeCon + CloudNativeCon Europe 2026 in Amsterdam, Broadcom made a landmark announcement by contributing its Kubernetes-native backup, restore, and migration project Velero to the Cloud Native Computing Foundation (CNCF) as a Sandbox project. This transition represents a significant shift in governance for one of the most critical tools in the Kubernetes ecosystem, moving from vendor stewardship to community control while maintaining its technical integrity and operational dependencies.

The Significance of the Donation

Velero operates at the Kubernetes API layer, capturing cluster state through Custom Resource Definitions (CRDs) rather than through hypervisor or storage-layer snapshots. This approach allows it to back up namespace definitions, persistent volume claims, RBAC policies, and other resource configurations as portable Kubernetes objects that can, in theory, be restored to a different cluster or distribution than the one from which the backup was taken.

With nearly 9,900 stars on GitHub, Velero has become an essential tool for platform teams managing stateful applications in Kubernetes. The donation to CNCCF addresses a critical need in the cloud native ecosystem: establishing trust through vendor-neutral governance while maintaining the project's technical capabilities.

Historical Context: From Heptio to Broadcom

Velero traces its origins to Heptio, the Kubernetes company founded by former Google engineers Joe Beda and Craig McLuckie, which VMware acquired in 2019. The project has been under VMware and subsequently Broadcom stewardship since then. This lineage explains why some organizations had hesitated to standardize on Velero precisely because of its single-vendor heritage.

"As organisations scale their cloud native workloads, the focus is shifting from simple orchestration to long-term resilience and data management. Velero provides a vital layer for backup and disaster recovery, ensuring that stateful applications remain protected. By joining the CNCF Sandbox, Velero gains a vendor-neutral home to foster community collaboration and growth."

-- Chris Aniszczyk, CTO, CNCF

Why This Matters: Trust and Governance

The donation is about more than just changing project governance—it's about repairing trust in the open source ecosystem. Dilpreet Bindra, Senior Director of Engineering for the VCF Division at Broadcom, emphasized that this is an investment rather than a divestiture:

"We're not just users of Kubernetes, we're builders, and we make Kubernetes easier to run, not harder."

Bindra directly addressed the trust dimension of the move, acknowledging that some observers might read the contribution as Broadcom walking away from a project it no longer believed in. He clarified that Velero is a tool the company intends to keep investing in as part of its VKS and IaaS story.

The Rack2Cloud architecture blog published a detailed analysis of the announcement, arguing that the governance change is as much about trust repair as about open source mechanics. The piece notes that Broadcom's own framing at the conference, specifically a comment about not wanting users to regard Velero as "a VMware thing," signals that the primary audience for the CNCF move is organizations that had hesitated to standardize on Velero precisely because of its single-vendor lineage.

Technical Architecture: How Velero Works

Velero's technical approach distinguishes it from traditional backup solutions. Rather than relying on hypervisor or storage-layer snapshots, Velero operates at the Kubernetes API layer, capturing cluster state through Custom Resource Definitions (CRDs). This design has several implications:

1. Portability: Backups are stored as Kubernetes objects in object storage, making them potentially portable across different Kubernetes distributions and cloud providers.

2. Storage as Source of Truth: The project treats object storage as the source of truth, continuously reconciling backup resources in the cluster against the contents of the configured storage bucket.

3. Cross-Cluster Discovery: A backup taken on one cluster can be discovered and restored by a Velero installation on a different cluster, provided it has access to the same storage location—a property central to its use in workload migration scenarios.

Velero Architecture (courtesy of StorageOS)

What Changes with CNCF Governance

The move to CNCF governance brings several important changes:

• Neutral Stewardship: The project is no longer perceived as a Broadcom/VMware tool, addressing concerns about vendor lock-in.
• Community-Driven Roadmap: Decision-making shifts to a broader community, including current maintainers from Broadcom, Red Hat, and Microsoft.
• CNCF Processes: The project adopts CNCF-aligned governance principles, including consensus-based decision-making with supermajority voting and a five-day lazy-consensus review period.

However, it's crucial to understand what doesn't change:

• Runtime Dependencies: Velero's dependencies on external object storage, IAM credential chains, and a functioning target cluster remain unchanged.
• Operational Requirements: The operational architecture requires the same engineering attention regardless of who governs the project.
• Existing Backups: Existing backups and restore procedures continue to work without modification.

Future Roadmap and Possibilities

While the immediate future of Velero remains stable, the community governance opens up several potential directions:

1. Centralized Control Plane: The techbytes.app analysis suggests the project may eventually include a centralized control plane for managing backup policies across multiple clusters.

2. CSI Integration: Improved integration with the CSI Data Management spec to support application-aware backups with pre-snapshot quiescing.

3. Signed Artifacts: Implementation of signed backup artifacts using Sigstore for enhanced security and verification.

4. Enhanced Observability: Deeper integration with CNCF observability tools like Prometheus and Grafana for backup monitoring.

These directions are described as anticipated rather than confirmed commitments, and the project's near-term roadmap will now be shaped by the broader maintainer community rather than by Broadcom alone.

Community Response and Maintainer Structure

The community response to the announcement was broadly positive. Orlin Vasilev, a CNCF Ambassador and former Velero contributor and community manager, wrote on LinkedIn:

"That took 'few' years to be seen as (the) next logical step, but still it's happening... Sooo happy to see that as ex-contributor and community manager for Velero, this is HUGE!"

The current maintainer list includes Broadcom, Red Hat and Microsoft, and the project's existing governance model already incorporates CNCF-aligned principles. One open question noted by observers is whether the maintainer composition will shift as community governance takes hold, and whether the project will move quickly through incubation toward CNCF graduation, given its extensive production adoption.

Related Broadcom Contributions

The Velero move was announced alongside several other Broadcom upstream contributions:

1. etcd Tooling: VMware published work with the etcd contributor community on diagnosis and recovery tooling at github.com/vmware/etcd-diagnosis and github.com/vmware/etcd-recovery, intended to give Kubernetes operators better visibility into control-plane health and simpler recovery paths from failures.

2. Cluster API Collaboration: Continued collaboration with the Cluster API (CAPI) community on cluster provisioning, upgrade orchestration and node lifecycle management.

RedMonk analyst James Governor described Broadcom's sustained contributions to the CNCF as "probably the best kept secret in the industry."

What This Means for Platform Teams

For platform teams evaluating the change, the governance shift removes a legitimate concern for organizations that previously avoided standardizing on Velero because of its VMware lineage. The operational architecture remains the same, requiring the same engineering attention regardless of who governs the project.

Organizations currently using Velero can continue their practices without disruption. New adopters may find increased confidence in the project's long-term viability and neutrality. The CNCF has published guidance on Kubernetes backup and migration strategies using Velero that predates this governance change and covers how the project handles cluster migration across providers.

Conclusion: A New Chapter for Kubernetes Resilience

Broadcom's donation of Velero to CNCF represents a significant moment in the evolution of cloud native infrastructure. By transitioning stewardship to a neutral foundation, Broadcom has addressed trust concerns while maintaining its commitment to the project. For the Kubernetes community, this move provides greater confidence in a critical tool for backup, restore, and migration operations.

As organizations increasingly rely on Kubernetes for stateful workloads, tools like Velero become essential for operational resilience. The CNCF governance model ensures that this essential tool will continue to evolve based on community needs rather than vendor priorities, positioning Velero for sustained growth and adoption in the years ahead.

For more information:

• Velero GitHub Repository
• CNCF Velero Sandbox Page
• Velero Documentation
• KubeCon + CloudNativeCon Europe 2026