Changelog

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.

We're excited to announce vCluster Platform v4.9 and vCluster v0.34, a release focused on resilience and operational simplicity for teams running vCluster as critical production infrastructure.

From active/active Multi-Region Platform deployments and standalone snapshotting to an overhauled template authoring experience and simpler vNode licensing, these updates make Platform easier to run, recover, and scale wherever you deploy it.

Multi-Region Platform

vCluster Platform now runs active/active across regions. Both regions serve traffic concurrently behind Route 53 latency-based routing, with leader election coordinating writes to a shared database and automatic DNS failover on regional outage. Launching with AWS support, clusters on this release can use either Postgres or MySQL as backing stores on RDS.

Configuration layers a multiRegion stanza on top of a standard Platform install. Each region gets its own values file specifying its own multiRegion.region and multiRegion.host. All regions share the same config.loftHost and config.database.dataSource:

config:
  loftHost: multi-region.example.com
  database:
    enabled: true
    dataSource: ${RDS_CONNECTION_STRING}
    identityProvider: aws
    extraArgs:
      - --datastore-max-open-connections=20
      - --datastore-max-idle-connections=0
  costControl:
    enabled: false  # not compatible with multi-region mode

multiRegion:
  enabled: true
  region: us-east-1
  host: us.multi-region.example.com

replicaCount: 3

See the full AWS walkthrough (VPC peering, Route 53 health checks, IAM database auth with Pod Identity, cross-region relay) in the docs.

Template Creation Overhaul

Templates allow administrators to enforce governance while providing users flexibility through configurable parameters.

Historically, the UI has offered limited support for managing those parameters. Parameters are now first-class in both the built-in YAML editor and the configuration UI, making them easy to create, reference, and edit.

Snapshot Support for Standalone

vcluster snapshot create now supports capturing the full control-plane state, including etcd and configuration, of a vCluster deployed directly to baremetal or VMs with use of the --standalone flag. Write the snapshot to S3, OCI, or a local container path, using the same snapshot semantics used for a vCluster deployed on a Kubernetes cluster.

export ACCESS_KEY_ID=...
export SECRET_ACCESS_KEY=...
export SESSION_TOKEN=...

vcluster snapshot create --standalone \
  "s3://my-bucket/my-snapshot.tar.gz?access-key-id=$ACCESS_KEY_ID&secret-access-key=$SECRET_ACCESS_KEY&session-token=$SESSION_TOKEN"Pass credentials inline in the snapshot URL (base64-encoded, as shown) or sourced from local AWS config and environment variables.

The bootstrap pattern. Deploy vCluster to baremetal or VMs, install vCluster Platform on top, then snapshot. You end up with a portable, restorable image of a fully-configured Platform control plane that is usable for disaster recovery, promoting from staging to prod, or cloning Platform installs across environments.

For more information please take a look at the docs.

vNode Licensing Improvements

With this release we are significantly improving how vNode handles licensing. Today, you must reference a platform host and platform access key when deploying vNode by its Helm chart. This creates a small, additional management surface area of key issuance / management.

Starting with this release any worker node or tenant control plane cluster attached to the vCluster Platform can deploy vNode with no access key / platform host. You can retrieve its license directly from the connected platform. Learn more in the vNode docs.

Breaking Changes

• Last year we announced our new Rancher OSS integration. With this release we have removed the legacy Rancher integration, including the authentication mechanism that allowed users to log in to our Platform with Rancher. Users must migrate to our new integration before upgrading.

• With the introduction of Multi-Region Platform, the Multi-Region-Mode feature has been renamed to Regional Cluster Endpoints.

Other Announcements & Changes

• Our Backup & Restore feature now supports Azure Blob storage as a backend using both the CLI and our auto-snapshots feature. The feature also supports S3-compatible paths.

• Virtual clusters created from the platform now default to embedded etcd as the backing store, replacing sqlite.

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