Broadcom Donated Velero to CNCF — Here's the Backup Checklist a Self-Hosted PaaS Should Actually Run

At KubeCon + CloudNativeCon Europe 2026 in Amsterdam, Broadcom handed Velero — the tool most of the Kubernetes world uses to back up cluster state and persistent volumes — to the CNCF Sandbox. The headline everyone ran with was "vendor-neutral governance." The number nobody put next to it: CNCF's own project metrics put Sandbox-tier project archival at roughly 15-20% within three years, versus close to zero once a project graduates. Velero didn't graduate. It landed at Sandbox, the entry tier, one step above "experimental."

That's not a knock on the donation — it's a genuinely good move for a project that used to sit entirely inside one vendor's roadmap. But "governance changed" and "risk went away" are different claims, and if you're running Velero as the backbone of a self-hosted PaaS's disaster-recovery story — the thing standing between a bad kubectl delete namespace and a multi-day outage — the second claim is the one that matters. Below: what actually changed, why it matters more on an owned Cluster-API fleet than on a hyperscaler, and the concrete checklist for running Velero against your own object storage today, including the hedge against the 15-20% number.

What Actually Changed, and What Didn't​

Velero's lineage runs through Heptio, the company Kubernetes co-creators Joe Beda and Craig McLuckie founded after leaving Google, which VMware acquired in 2019. VMware became part of Broadcom in 2023 — the same acquisition whose licensing fallout has already forced fleets onto owned Kubernetes at a cost of 800-1,500% depending on core density. Velero rode inside that acquisition too, as a free tool wrapped around a company whose other pricing decisions gave every customer reason to ask what happens to the free tools next.

The donation answers that specific question. Velero's maintainer roster now includes engineers from Broadcom, Red Hat, and Microsoft — three organizations with competing commercial interests, which is precisely the point of vendor-neutral governance: no single acquirer can unilaterally change the license, fold it into a paid tier, or let it quietly die because it stopped mattering to one company's roadmap.

What didn't change is Velero's maturity tier. CNCF ranks projects Sandbox → Incubating → Graduated, and each step up requires demonstrable proof: adoption across multiple organizations, a Core Infrastructure Initiative Best Practices badge, a documented GOVERNANCE.md, and — critically for graduation — API stability and a slower rate of breaking changes. Velero entered at Sandbox, the tier CNCF describes as "early stage… failure as a possibility." The practical difference between the three tiers:

Velero already clears the bar Sandbox status implies is missing — Fidelity Investments alone runs it across 200 clusters, 1,000+ namespaces, and 10,000+ containers, and the GitHub repo carries 165 contributors and nearly 6,000 commits. The Sandbox label is a function of how recently it applied for CNCF status, not a verdict on its production-readiness. But labels are what compliance checklists and vendor-risk reviews actually read, and "CNCF Sandbox project" is a materially different line item than "CNCF Graduated project" on that form — worth knowing before you cite the donation as your derisking argument to anyone who asks.

Why This Matters More on a Bare-Metal Fleet Than on a Cloud VM​

Velero's actual mechanism is easy to undersell: it doesn't take hypervisor-level or storage-array snapshots. It works at the Kubernetes API layer — it reads your cluster's object graph (Deployments, ConfigMaps, CRDs, PVCs) through the API server and serializes it, then optionally triggers CSI volume snapshots or moves volume data through its own data-mover pods into object storage. That's what makes it portable across every Kubernetes distribution and every cloud, and it's also why it doesn't need a vSphere, EBS, or Azure Disk API underneath it to function.

That portability is table stakes if you're running a VM fleet with a vendor's storage layer under you, because that vendor's own backup product is a fallback. It becomes load-bearing the moment you're running a self-hosted PaaS on a Cluster-API-managed fleet of bare-metal or unmanaged-cloud nodes — Hetzner boxes, say, with no vSphere snapshot API and no managed-disk-snapshot service sitting underneath the cluster. On that architecture, Velero (or something architecturally identical to it) isn't a nice-to-have alongside the platform's own storage vendor tooling. It's the only DR mechanism in the stack, which is exactly why the honest read of "how mature is this dependency" from the section above isn't academic — it's the question that decides whether your platform has a real disaster-recovery story or a hopeful one.

The v1.18 Features That Actually Matter for a Backup-to-S3 Design​

Velero's v1.18 release (already shipped ahead of the CNCF move) added three changes that map directly onto the failure modes a multi-tenant, bare-metal fleet actually hits:

• Concurrent backup processing. Earlier Velero versions processed backups serially. For a single-tenant cluster that's a non-issue; for a self-hosted PaaS backing up dozens of tenant namespaces on independent schedules, serial processing means later-scheduled tenants' backups silently queue behind earlier ones during a busy window. v1.18 runs multiple backups at once, which is the difference between "every tenant's backup completes inside its window" and "the last few tenants alphabetically get a stale backup."
• Cache volume configuration for data movement. CSI-snapshot data movement and file-system backup both run through data-mover pods that stage data on the node's ephemeral disk before shipping it to object storage. On a node with a small or shared ephemeral disk, those pods fail outright, or multiple data movers on the same node collide over the same limited scratch space. v1.18 lets you configure a dedicated cache PVC for the mover pods, which turns "backup fails because the node ran out of scratch space" from a production incident into a capacity-planning line item.
• Incremental backup size visibility. You can now see how much a given backup actually reduced via incremental deltas — a real number to check against your retention math, instead of trusting that incremental backups are working.

None of these are exotic. They're the specific gaps that show up the first time you run Velero against a real multi-tenant fleet instead of a demo cluster, which is exactly why they belong in the checklist below rather than in a changelog nobody reads.

The Checklist: Running Velero Against Owned Hetzner Storage Today​

This is the part a "CNCF donation" news cycle skips: what to actually configure. For a Cluster-API fleet backing up onto Hetzner Object Storage (or any S3-compatible target), the concrete list:

1. Point the BSL at S3-compatible object storage, not local disk. Install the AWS-compatible plugin and configure a BackupStorageLocation with Hetzner Object Storage's endpoint and region. Object storage outlives any single node in the fleet — a local-disk backup target defeats the entire point of a DR story.
2. Scope BSL credentials to least privilege. Create a dedicated Secret with write-only access to the backup bucket (velero create secret ... --credential), not the same key your CI pipeline uses for anything else. A compromised backup credential should not be able to touch anything but backups.
3. Configure a second BSL against a different provider or account. Velero has supported multiple BSLs with independent credentials since v1.6 — use it. Point BSL #2 at a second object-storage account (a different Hetzner project, or a second provider entirely) on a lower-frequency schedule. This is the direct hedge against the 15-20% Sandbox-archival number: if Velero itself ever stalls or forks, your actual backup data isn't hostage to one tool's continuity — it's sitting in plain object storage two independent providers deep, restorable by whatever backup tool exists at that point.
4. Size a dedicated cache PVC for data-mover pods (v1.18) on every node class that runs CSI-snapshot or fs-backup jobs — at minimum 2x your largest single PVC's expected incremental delta, so a mover pod never contends with node ephemeral disk under load.
5. Schedule backups by tenant-namespace label selector, not one fleet-wide job. Use Velero's --selector scoping so each tenant namespace has its own schedule and retention policy, and take advantage of v1.18's concurrent processing so tenant N's backup isn't queued behind tenant 1's.
6. Set retention to match your actual recovery-point objective, then verify it against the incremental-size metric (v1.18) — don't assume the retention window you configured is the retention window you're getting; confirm the delta sizes are what you expect for the schedule you set.
7. Run a restore drill on a real schedule, into a scratch namespace, not a mental checklist. An untested backup is a hypothesis. Quarterly at minimum; monthly if the fleet is multi-tenant production.
8. Alert on backup failure, not just on backup non-completion. A silently-failing nightly job you don't get paged for is functionally the same as no backup at all.

Line 3 is the one most teams skip, and it's the one that actually answers the CNCF-Sandbox risk question from earlier — not by hoping the project's governance holds, but by making sure your recovery point doesn't depend on it holding.

The Honest Verdict on Load-Bearing Risk​

Should a self-hosted PaaS treat Velero as load-bearing DR infrastructure? Yes — with the multi-BSL hedge above, and with eyes open about what "CNCF Sandbox" does and doesn't buy you. It buys you multi-vendor maintainership and a real path off single-company control. It doesn't buy you Incubating-grade API stability or graduation-grade adoption guarantees, and the honest comparison isn't "free CNCF tool vs. nothing" — it's "free CNCF tool with a real but bounded continuity risk vs. a paid commercial alternative like Kasten K10 or Portworx PX-Backup, which trade that risk for a different one: a support contract and a vendor who can reprice it the same way Broadcom just repriced VMware." Velero's donation doesn't erase that tradeoff. It just moves Velero from "single vendor's roadmap" to "community project with real but quantifiable Sandbox-tier risk" — which is a better place to build on, provided your architecture doesn't pretend the risk hit zero.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, on a Cluster-API-managed fleet where exactly this kind of backup-and-restore story is part of the platform, not an afterthought. Star the repo on GitHub or deploy your first app today.