Changelog

vCluster Platform 4.12 and vCluster 0.37 move beyond tenant clusters to the complete environments around them. Define reusable environments with Stacks, run them on broader infrastructure, protect them with stronger recovery, and operate them through GitOps and fleet observability.

Deploy complete application environments with Stacks

With Stacks, platform teams can turn a collection of application components into a reusable, self-service building block. Define an environment once, expose the parameters its users should control, and deploy it consistently to a tenant cluster or control plane cluster. Teams can install a Stack from those available to them, add it during tenant-cluster creation, or declare it through vcluster.yaml so its lifecycle follows the cluster.

Stacks coordinate more than installation. Applications without dependencies can deploy concurrently, while dependent tasks wait for health gates and can consume values captured from earlier tasks. Each application remains a long-lived installation with its own status and logs, while the Stack provides an aggregate view and keeps ownership and cleanup tied to the deployment. Teams retain one durable place to understand and manage the complete environment through day-2 operations.

The underlying StackTemplate and StackInstance custom resources define the reusable offering and each deployment. They can be made of any combination of AppInstance or ArgoCDApplication. This provides the managed application foundation, replacing the older Task and HelmRelease installation path.

Deploy Run:ai with a certified Stack

Platform 4.12 includes certified NVIDIA Run:ai Stacks, giving platform teams a ready-to-use path for deploying Run:ai as a complete tenant environment. The bundled templates coordinate registry setup, ingress, TLS, NVIDIA GPU components, the Run:ai control plane, tenant registration, and cluster agents in reusable, dependency-aware workflows. Teams can deploy these components consistently while retaining the status, logs, lifecycle management, and cleanup provided by Stacks.

For hard multitenancy at the Run:ai control-plane layer, the dedicated model gives each tenant an independent Run:ai control plane and GPU Operator lifecycle. For trusted soft-multitenant environments, the central model installs the shared host foundation once and reuses its Run:ai control plane and GPU Operator while keeping registration and runtime resources separate for each tenant. Both bundled tenant templates use shared control plane cluster nodes by default; node labels control scheduling, not runtime isolation. Add private nodes when node-level tenant isolation is required.

Argo CD and Fleet Observability now included in the Free tier

The rollout of Stacks expands Platform’s Argo CD-based application workflows. Alongside that work, the Argo CD integration and Fleet Observability, previously starting at the Dev tier, are now included in the Free tier. Anyone running vCluster Platform can register tenant clusters and control plane clusters with Argo CD and monitor them through the bundled Fleet Observability stack without a paid license. See the Argo CD integration and Fleet Observability docs for setup steps.

Protect environments with stronger snapshot recovery

Complete environments need dependable recovery as well as repeatable deployment. Before a restore begins, vCluster verifies that it can access the requested snapshot. Expired or invalid S3 credentials now fail before the control plane is restarted, so an unsuccessful recovery attempt does not create unnecessary downtime.

Teams can also better protect snapshots at rest. S3-backed snapshots support server-side encryption, including customer-managed KMS keys, while object-store credentials are stored in a Kubernetes Secret instead of being embedded in the control-plane Pod specification.

Scheduled snapshot coverage now includes Azure Blob Storage alongside existing S3-compatible paths. Platform can also configure and manage automatic snapshots for standalone tenant clusters, bringing scheduled protection into the same workflow used for other Platform-managed clusters. vCluster can convert embedded-etcd snapshots when restoring into another supported backing store, including deployed etcd or a supported external database target. Together, these changes make snapshots a more dependable and flexible recovery mechanism across supported datastores and storage providers.

Breaking Changes

App deployment APIs have changed

Platform removes the Task API, HelmRelease API, the legacy virtual cluster API group, and the related chartinfos, clusters/charts, and projects/charts discovery endpoints as part of the move to long-lived AppInstance resources. Automation that installs apps through Tasks or HelmReleases, or discovers charts through those endpoints, must migrate to AppInstance and the new app APIs.

Standalone snapshot credentials must be stored in the Platform project namespace

For standalone tenant clusters, snapshots.auto.storage.<provider>.credential.secretNamespace is no longer supported. Platform always resolves the Secret named by secretName from the same project namespace as the VirtualClusterInstance. Before upgrading, copy or recreate affected S3, OCI, or Azure credential Secrets in that namespace, then remove secretNamespace from the virtual cluster configuration or template. Pod-based tenant clusters are unaffected.

Before upgrading a standalone tenant cluster:

snapshots:
  auto:
    storage:
      type: s3 
      s3: 
        credential: 
          secretName: aws-cred 
          secretNamespace: backup-secrets 

For standalone tenant clusters in Platform 4.12:

snapshots:
  auto:
    storage:
      type: s3 
      s3: 
        credential: 
          secretName: aws-cred 

The aws-cred Secret must exist in the Platform project namespace containing the VirtualClusterInstance. Apply the same change to OCI or Azure credentials that set secretNamespace.

Kubernetes Version

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

Additional improvements

• Restore CSI VolumeSnapshot synchronization. vCluster again syncs VolumeSnapshot and VolumeSnapshotContent resources to the host cluster and VolumeSnapshotClass resources into the tenant cluster. This corrects an unintentional removal in v0.36 that affected customers using CSI snapshot resources. The separate removal of snapshot-managed volume backup and restore is unchanged.

• Run private-node workloads on more infrastructure. Platform adds KubeVirt CSI for stateful workloads, GPU and PCI passthrough, Netris-backed networking for Metal3, and Kube-OVN load balancing and pod routing.

• Let Argo CD-managed tenant clusters sleep. Argo CD polling no longer resets the inactivity timer for onboarded tenant clusters, allowing sleep mode to suspend clusters that would otherwise appear continuously active.

• Set properties per node pool. Static and dynamic node pools can override provider-level properties for the NodeClaims they create, giving platform teams more control over different pools without duplicating the provider configuration.

• Meter GPU usage across more accelerator vendors. Platform now counts AMD, Intel—including Gaudi—AWS Neuron, and Google TPU accelerators alongside NVIDIA and reports usage by vendor and resource type. Existing environments using non-NVIDIA accelerators may report a higher billable GPU total after upgrading.

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.

Native GitOps workflows with first-class Argo CD integration

vCluster Platform now brings Argo CD directly into the tenant cluster lifecycle. Platform teams can connect self-hosted Argo CD or Akuity once, then let Platform automatically register tenant clusters and control plane clusters, manage Argo CD Applications, and deploy workloads as part of the vCluster workflow.

With the new declarative app deployment model, teams can attach applications directly to a vCluster configuration:

integrations:
  argoCD:
    enabled: true
    connector: argocd-main

deploy:
  argoCD:
    applications:
      - name: platform-observability
        displayName: Platform Observability
        target: vcluster
        destinationNamespace: monitoring
        template:
          name: observability-stack

This turns GitOps into a built-in platform capability instead of a manual handoff between cluster provisioning and application delivery. A tenant vCluster can now be created with the applications it needs already declared, while Platform handles Argo CD cluster registration, application synchronization, and cleanup.

For control plane cluster deployments, Platform admins can also use standard Argo CD destination targeting. An Argo CD Application with spec.destination.cluster.name set to the target control plane cluster, such as loft-cluster, will deploy directly to that control plane cluster. This gives admins a practical GitOps-native way to manage platform-level agents, shared services, and other control plane workloads without needing to model everything through target: host in a vCluster configuration. The target: host option remains useful when an application should be declared as part of a specific vCluster workflow, while direct Argo CD cluster targeting is the better fit for broader control plane cluster administration.

With this release, the original Argo integration is now deprecated and has been labelled as legacy.

For setup details, see the Argo CD integration docs.

Platform: Virtual Machine Management Arrives

Note: VM Management is launching as an experimental feature. If you’re interested in being a design partner for VM Management, let us know! You will need a license with a special feature flag enabled.

Platform now introduces virtual machines as a first-class resource in the Nodes experience. Previously, the Machines view focused on bare metal infrastructure. With this release, Platform expands that model to surface and manage VMs alongside physical machines. This gives platform teams a unified place to understand, provision, and operate compute across both bare metal and virtualized environments.

For KubeVirt-backed infrastructure, teams can now work with virtual machine details directly in Platform, including OS image selection, DataVolume-backed root disk configuration, and network/interface settings such as NetworkAttachmentDefinitions. The updated all-projects Machines view and VM detail pages make it easier to see where workloads are running, inspect VM status, review related KubeVirt resources, and manage virtualized infrastructure without jumping between provider-specific tools.

Gateway API support for modern routing and sleep mode

vCluster Platform v4.10 and vCluster v0.35 introduce Gateway API support as a modern, Kubernetes-native alternative to traditional Ingress-based networking. This gives platform teams a more expressive and standardized way to expose Platform, expose individual vCluster control plane APIs, route tenant traffic, and manage shared entry points across different Gateway controllers.

With this release, Platform can configure Gateway-based endpoints, vCluster can expose individual control planes through TLSRoute, and shared-node vClusters can sync Gateway API resources between tenant clusters and control plane clusters. Admins can also provide approved, read-only control plane cluster Gateways for tenants to attach routes to, which lets central platform teams own shared networking infrastructure while still giving tenants a self-service routing model.

The practical takeaway: customers can start adopting Gateway API without moving everything at once. Existing Ingress-based configurations continue to work, and there is no automatic Ingress-to-Gateway conversion in this release. Teams can validate their preferred Gateway controller and GatewayClasses, move new or selected vClusters to Gateway-backed endpoints, and plan broader migration on their own timeline. For customers specifically planning around ingress-nginx deprecation and future removal, the ingress-nginx to Gateway API migration guide is the place to start evaluating the forward path.

Gateway API support also extends sleep mode for compatible controllers. When a Gateway controller supports HTTPRoute request mirroring, Platform can continue tracking activity, route traffic through the wake-up path while a vCluster is asleep, and restore normal routing when it wakes. That makes Gateway API valuable not just for traffic management, but also for customers relying on sleep mode to control cost and resource usage.

Kubernetes Version

With this release, vCluster uses Kubernetes 1.36 by default.

To pin a different version, specify controlPlane.distro.k8s.image.tag in vcluster.yaml.

Breaking Change

• Database connector PostgreSQL TLS behavior - Database connector now tightens PostgreSQL connection security instead of relying on the previous fallback behavior that could allow connections without encrypted transport. Customers using database connector with PostgreSQL should verify that their database endpoint supports TLS and update connector configuration as needed, including sslMode and caCert when certificate verification is required. Environments that depended on unencrypted PostgreSQL connections may need configuration changes before upgrading.

Deprecation

• Volume snapshot - Volume snapshot restore for CSI persistent volumes is now deprecated and slated for removal in an upcoming release. No immediate action is required in vCluster v0.35, and existing usage continues to work for now. If you rely on volume snapshots through backup --include-volumes or restore --restore-volumes, start planning how you will handle persistent data once the feature is removed. Good first steps are to inventory which vClusters depend on volume snapshot backup/restore, confirm what data must be protected at the application or storage layer, and evaluate replacement backup/restore workflows before removal becomes a blocker.

• Deployed etcd migration option deprecation - The embedded.migrateFromDeployedEtcd option is now deprecated and is planned for removal in a future release. Existing one-time migrations that already used this option are not affected, but customers planning to move from deployed etcd to embedded etcd should use vCluster snapshot and restore instead. Snapshot and restore is the recommended migration path because it provides a more reliable way to capture vCluster state, restore it into a new embedded-etcd-backed vCluster, and validate the new cluster before removing the old deployed-etcd-backed cluster. Because backing store configuration is immutable, teams should plan this as a migration to a replacement vCluster rather than an in-place backing-store change.

Highlighted Changes

• Platform now supports Helm chart secret references for the agent connection token and admin password in the Platform Helm chart. This lets customers reference pre-existing Kubernetes Secrets instead of materializing sensitive values directly through chart values, which is especially useful for teams with stricter secret-management and GitOps requirements.

• Platform improves external peers and Tailscale SSH, including UI support for custom clients and better route advertisement behavior. These updates make it easier to manage connectivity paths from Platform without relying on manual configuration outside the UI.

• Project users and viewers now get the permissions needed to actually see infrastructure tabs, node claims, and node environments where appropriate. This fixes cases where users could reach pages but see empty or incomplete data, making project-level infrastructure views more useful for day-to-day operations.

• Node claim deletion and provisioning paths are more transparent and resilient. Destroy failures now surface as failed status conditions, provisioning no longer blocks when a provider cannot report a node IP, Terraform node-environment bootstrap retries are more accurate, and stale deleted users/teams are cleaned up from project membership.

• The Platform UI got a broad navigation and table polish pass. The sidebar overhaul, separated name/status columns, better vCluster creation tenancy/backing-store flow, clearer template warnings, and multiple table/readability fixes make the product easier to scan and more predictable for repeated administrative workflows.

• vCluster node upgrade now correctly forwards --bundle-repository into the upgrade pod, and vCluster Pro can upgrade vcluster-vpn in place when the bundled tunnel is newer. This is especially important for private-node and air-gapped workflows where upgrade bundles are served from a controlled endpoint rather than GitHub. Upgrades become less brittle and more predictable.

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