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.