Kubernetes 1.36's Volume Group Snapshots Go GA: Can Your Self-Hosted Fleet Actually Use It?

Kubernetes 1.36 shipped on May 8, 2026 and graduated VolumeGroupSnapshot to General Availability — a real, stable API for taking a crash-consistent snapshot across multiple PersistentVolumeClaims at once. If you're running a self-hosted, Cluster-API-managed fleet on plain Hetzner Cloud Volumes or Longhorn — the two most common storage backends for that setup — the honest answer is: you can't use it yet. Neither storage driver implements the CSI extension the feature depends on. The one path that works today runs through Ceph, and even there it's narrower than the GA announcement makes it sound.

The problem this actually solves​

Plenty of stateful workloads split their data across more than one volume on purpose. A database keeps its data files on one PersistentVolume and its write-ahead log on another, because separating them improves I/O performance. A tenant app might keep a data volume and a log/cache volume side by side for the same reason. That split creates a restore problem the single-volume snapshot API was never built to solve: if you snapshot each volume independently, even a few seconds apart, you can end up restoring a WAL that's ahead of — or behind — the data it's supposed to replay against. The app comes back up in a state it never actually was in.

VolumeGroupSnapshot, promoted to GA under the groupsnapshot.storage.k8s.io/v1 API group in 1.36, closes that gap. You label the PVCs that belong together, point a VolumeGroupSnapshotClass at a label selector, and the CSI driver snapshots every matching volume atomically, at the same instant — no need to pause or quiesce the app first. Three new API objects do the work: VolumeGroupSnapshot (what you create to ask for one), VolumeGroupSnapshotContent (the system-created binding to the underlying storage snapshot), and VolumeGroupSnapshotClass (the admin-defined policy — which driver, what deletion behavior). Restoring is still per-volume: you take the individual VolumeSnapshot objects the group produced and provision new PVCs from each as a dataSource, same as today — but because every one of those individual snapshots was taken at the same point in time, the data and the WAL restore into a state the app actually passed through.

That's a meaningful upgrade for any platform running multi-volume stateful workloads. It's also, per the Kubernetes API's own fine print, CSI-only — in-tree volume plugins don't get it, and the feature works only if the specific CSI driver underneath your StorageClass chose to implement the group-snapshot extension. That last clause is where the actual answer to "can I use this" lives, and it isn't the same for every fleet.

What "GA" actually guarantees — and what it doesn't​

It's worth being precise about what graduating to groupsnapshot.storage.k8s.io/v1 actually locks in, because "GA" gets read as "ready to use" more often than it should. What GA guarantees is API stability: the schema for VolumeGroupSnapshot, VolumeGroupSnapshotContent, and VolumeGroupSnapshotClass won't change out from under you the way a beta or alpha field can. Kubernetes itself — the API server, the snapshot controller, the validating webhook — fully supports the contract today. What GA does not guarantee is that any particular storage backend implements the other half of that contract: the CSI driver has to translate a VolumeGroupSnapshot request into an actual atomic, multi-volume operation against its own storage system, and that's driver-specific work that happens on its own timeline, entirely decoupled from the Kubernetes release that stabilized the API surface above it. This is the same pattern that played out with the original single-volume VolumeSnapshot API, which reached GA in Kubernetes 1.20 back in December 2020 — plenty of clusters ran 1.20 for a year or more before their storage vendor shipped snapshot support at all. A stable API and a working implementation are two different milestones, and the gap between them is exactly where a fleet operator's actual planning has to live.

The support matrix that decides whether this API means anything to you​

This isn't a survey of every CSI driver in the ecosystem — plenty of other options exist (Piraeus/LINSTOR-DRBD and OpenEBS among them), and their group-snapshot status is worth checking independently if you run either. What follows is the two storage backends a self-hosted, Cluster-API-Provider-Hetzner (CAPH) fleet is actually likely to be running by default, plus the one alternative that currently supports the feature:

That table is the actual finding: the GA milestone means the Kubernetes API contract is stable and won't change out from under you, not that every storage layer honors it. If your fleet runs bare Hetzner Volumes or Longhorn today — the two defaults for a CAPH cluster that hasn't deliberately added a distributed storage layer — this feature is currently a spec you can read, not a button you can press.

Why this belongs in the infrastructure layer, not a database feature​

The part of the original promise worth taking seriously anyway: this is a CSI-layer guarantee, not something a platform has to build and operate itself. A self-hosted PaaS that wants to offer tenants a "back up this app" button has historically had two bad options — snapshot each volume separately and accept the inconsistency risk, or build (and operate) its own database-aware backup logic per data engine, which is exactly the kind of managed-database surface a platform like Bex.co doesn't want to own. VolumeGroupSnapshot is a third option: a primitive the storage driver provides, that a platform's control plane can call generically — label the volumes belonging to one app, request a group snapshot, done — without knowing or caring whether the app is Postgres, Redis, or something a tenant wrote themselves. The distinction matters for what a self-hosted platform can honestly promise a tenant: "your app's volumes are captured consistently" is an infrastructure-layer fact the CSI driver either delivers or doesn't, not a feature roadmap item the platform team has to prioritize, staff, and maintain per database engine.

For a fleet that's already standardized on Rook-Ceph — which plenty of Kubernetes-native storage setups do specifically for its resilience and feature completeness — putting that button in front of tenants today is a matter of shipping a VolumeGroupSnapshotClass and labeling app volumes consistently at provision time. The class defines the policy once, cluster-wide:

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshotClass
metadata:
  name: rook-ceph-cephfs-groupsnapshot
driver: rook-ceph.cephfs.csi.ceph.com
deletionPolicy: Delete
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/group-snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/group-snapshotter-secret-namespace: rook-ceph

Then every backup request the platform issues on a tenant's behalf is just a label match against that class:

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
  name: tenant-app-42-backup
spec:
  volumeGroupSnapshotClassName: rook-ceph-cephfs-groupsnapshot
  source:
    selector:
      matchLabels:
        bex.co/app-id: "tenant-app-42"

Every PVC belonging to that app gets the same bex.co/app-id label at creation time; the group snapshot request itself never has to know how many volumes that app has or what's on them. Restoring still goes through the individual VolumeSnapshot objects the group produced — one new PVC per original volume, each pointed at its own snapshot as a dataSource — but because the platform controls provisioning end to end, that fan-out is something the control plane does automatically rather than something a tenant has to reassemble by hand.

The cost side of the one path that works​

None of that recipe is free, and skipping the cost is exactly the kind of hand-wave this piece is trying not to make. Rook-Ceph isn't a driver you swap in — it's a distributed storage system, with its own MON quorum (three or five nodes for real fault tolerance), OSD placement across physical disks, and a meaningfully larger operational surface than either Hetzner's managed Volumes or Longhorn's simpler local-disk replication model. A team currently running bare Hetzner Volumes because it's the zero-maintenance default gets a real backup primitive by adopting Ceph, but they're also taking on a storage system that needs monitoring, capacity planning, and its own upgrade discipline — a fair trade for a platform that needs group-consistent snapshots today, not a free upgrade.

What to actually do with this today​

If your fleet is already Ceph-backed and using CephFS for multi-volume workloads, this is usable now — the recipe above is close to production-ready, modulo your own naming and retention policy. If you're running plain Hetzner Cloud Volumes or Longhorn, the honest options are narrower: file (or upvote) the upstream issues linked above, since driver-level support is what's actually blocking you, not anything you can configure around; or, if group-consistent backup for multi-volume stateful workloads is a real requirement today, weigh the operational cost of standing up Rook-Ceph above against waiting on a backlog item with no committed date. Neither is a quick fix, and pretending otherwise would undersell exactly the gap this GA announcement doesn't close on its own.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, orchestrated by Cluster API. When the storage layer underneath it supports primitives like VolumeGroupSnapshot, a platform can offer real backup guarantees without ever having to operate a database service itself. Star the repo on GitHub or deploy your first app today.