Release Date: July 21, 2026

vCluster Platform v4.11 and vCluster v0.36 focus on day-2 operations for tenant clusters: built-in monitoring for platform admins, consistent configuration for private-node fleets, and clearer recovery guidance for backing-store incidents.

Fleet Observability

On shared infrastructure, platform admins need one fleet-wide view, while each tenant needs a safe, isolated slice of the same data. Building this by hand often means per-tenant Prometheus deployments and brittle access rules. vCluster Platform v4.11 introduces Fleet Observability, giving platform admins one fleet view from which they can drill into tenant and control plane clusters that need attention. This initial release focuses on metrics. Logs and traces are not part of the Fleet Observability pipeline.

When admins deploy the optional bundled Grafana application template and configure the Observability Connector, Platform embeds fleet, cluster, and GPU dashboards. The connector can use the bundled Prometheus backend or another metrics backend that accepts OTLP metrics and provides a Prometheus-compatible HTTP query API.

OpenTelemetry collectors write metrics to a single backend through an authenticated gateway that stamps trusted Platform labels. Dashboard and API requests pass through the vCluster-provided query proxy that scopes PromQL to the control plane clusters or tenant clusters the authenticated identity can read. Together, authenticated labels and query rewriting enforce tenant-isolated access over a shared metrics backend. Platform dashboard views are available to platform admins, while direct API clients can use scoped metrics-reader access keys.

Ready-to-deploy metrics stack

For teams that want a ready starting point, Platform includes Argo CD application templates for the metrics stack. The bundled Prometheus template accepts OTLP metrics. The Grafana template integrates with Platform SSO and provides fleet, cluster, and GPU dashboards. OpenTelemetry collector templates collect workload, Kubernetes, node, and optional GPU metrics. Admins create applications from these templates for the backend, Grafana, and the clusters they want to monitor.

GPU health and operations

For AI and GPU fleets, the same metrics path surfaces GPU-specific signals alongside tenant and control plane cluster health. Fleet Observability includes a GPU dashboard and collector scrape paths for exporters such as DCGM.

Separate GPU application templates help admins deploy NVIDIA GPU Operator, NVSentinel, and NVIDIA Fleet Intelligence Agent. These applications operate independently of Fleet Observability, but their metrics can feed the same Platform-centered operating view.

As more teams and clusters share the platform, Fleet Observability gives admins a clearer starting point for everyday operations. Admins can see the fleet, find the cluster that needs attention, and follow its metrics without leaving Platform.

Group private nodes and keep them configured

vCluster Platform v4.11 introduces NodeProfile as a way to group private nodes and maintain their configurations in common. Platform admins define named profiles with the labels, annotations, and taints that should apply to any node referencing them, and the platform keeps those settings in sync continuously, not just at join time. Editing a profile pushes the change out to every node that already uses it, without rejoining or replacing the node. Profiles can also apply startup taints that hold a new node out of scheduling until setup finishes, then clear automatically once it's ready.

Profiles apply the same way across manual joins and auto-node pools, including both static and dynamic pools. A node gets the right configuration no matter how it was provisioned, without teams hand-rolling their own join scripts or one-off per-pool settings. Application teams can target the right capacity with familiar Kubernetes scheduling controls, while platform teams manage the configuration from a single place.

Project admins can curate which profiles a project is allowed to use and set a project-level default for nodes that don't select one explicitly. A tenant cluster's own default (privateNodes.defaultProfile) always takes precedence over the project default, so platform teams get a safe baseline per project, while application teams can still opt into specialized profiles where they're allowed. Because the assignment is enforced through a protected node label that only the platform can set, a node can't grant itself a different profile after it joins.

Node profiles also make private-node operations easier to reason about as fleets grow. A node no longer joins as an undifferentiated machine that needs follow-up patching. Instead, it joins with its labels, annotations, and taints already applied, and stays in sync with its profile for as long as it's part of the tenant cluster.

Breaking Change

• CSI volume snapshot backup and restore has been removed. vCluster v0.35 deprecated CSI volume snapshot backup/restore for persistent volumes. In vCluster v0.36 and Platform v4.11, the volume snapshot implementation, CSI snapshot controller deployment, VolumeSnapshot syncers, and related API fields have been removed. Existing sync.toHost.volumeSnapshots, sync.toHost.volumeSnapshotContents, and sync.fromHost.volumeSnapshotClasses configuration is retained only as a no-op so older configs can still parse. Customers that previously relied on backup (--include-volumes) or restore (--restore-volumes) should move persistent data protection to application-level or storage-provider-native workflows, such as Velero-based backups, and use vCluster snapshots for vCluster state.

• ArgoCD Application names now include a Platform instance hash. To avoid collisions when two or more Platform instances deploy same-named tenant clusters with the same applications into a shared ArgoCD, the computed ArgoCD Application name now includes the Platform instance ID as a hash suffix. Platform migrates existing Applications automatically without deleting managed workloads. Teams using the Argo CD integration should confirm their Applications reconcile cleanly after upgrading.

Deprecation

• Moving tenant clusters between projects by API is deprecated. The API for moving virtual clusters between projects is being deprecated. Customers should plan to create tenant clusters directly in the intended project and avoid building new automation around cross-project moves.

• Legacy token forwarding boolean is deprecated. Platform now uses an explicit token forwarding mode for tenant clusters. Existing forwardToken configuration remains compatible, but new configuration should use the forwardTokenMode enum instead of the legacy boolean.

Kubernetes Version

This release uses Kubernetes 1.36 by default (v1.36.0).

Additional improvements

• Tenant cluster troubleshooting gets more complete. Platform includes updates to the tenant cluster status experience, host-cluster drilldowns, vCluster logs in Platform, VPN diagnostics, and Gateway API inspection paths so admins have more context when they investigate a cluster.

• Template-backed tenant cluster creation is easier to review. The Platform UI now shows template summaries and template parameters during creation, making template-backed clusters easier to understand before users create them.

• Standalone clusters can set an explicit advertise address. vCluster now supports controlPlane.standalone.advertiseAddress, which is useful when the address advertised to peers should differ from the address vCluster would auto-detect.

• Task execution moves in-process (runner removed). Platform no longer uses a standalone runner. App and template tasks now run in-process in the Control Plane Cluster (bounded by LOFT_MAX_CONCURRENT_TASKS). Task logs are stored per-task in Kubernetes secrets rather than streamed through a runner. There is no user-facing API change, but self-hosted setups that provisioned dedicated runner peers (for example, Tailscale runner peers, runner access keys) no longer need them. Review any automation that assumed a separate runner.

• Node join tokens now last 24 hours. Bootstrap tokens used by autoscaling worker-node user data and tenant cluster join scripts now expire after 24 hours instead of 1 hour. This makes provisioning and join flows more resilient in the case of token expiry.

For a list of additional fixes and smaller changes, refer to the vCluster release notes, the vCluster Pro release notes, and the vCluster Platform release notes. For detailed documentation and migration guides, visit vcluster.com/docs.