🚀 New Features

Namespace-Scoped RBAC for Agentless Watches
sveltos-agent and drift-detection-manager, in agentless mode, previously assumed they could watch and list any resource anywhere, and would just 403-loop against a kubeconfig whose RBAC is scoped to a subset of namespaces. Both now support a --watch-namespaces flag: the watch registry keys watchers by (GVK, namespace) instead of a bare GVK, so a ResourceSelector with an explicit namespace watches just that namespace, and an empty ("match anywhere") selector fans out across only the configured namespaces instead of cluster-wide. Cluster-scoped resources are always let through.

Nothing needs to be set on the agents directly: a managed Cluster/SveltosCluster can carry the annotation agent.projectsveltos.io/watch-namespaces (a comma-separated namespace list), and addon-controller and classifier relay it down automatically. addon-controller passes it to drift-detection-manager's --watch-namespaces flag when deploying it in agentless mode, and also scopes its own stale-resource cleanup search to the same namespaces, so its own RBAC-restricted credential doesn't 403 on cleanup either. classifier does the same for sveltos-agent, threading the annotation into the manifest it deploys and folding its value into the deployment's config hash so a changed annotation triggers a redeploy rather than being silently ignored.
PRs: addon-controller #1939, classifier #504

Generic OIDC Workload Identity Provider
WorkloadIdentityConfig gains a fourth provider, OIDC, alongside AWS/GCP/Azure: a standard RFC 6749 client credentials grant against any compliant IdP (Dex, Keycloak, Okta, and similar), for managed clusters not on one of the three cloud providers with their own federation mechanism. Unlike the cloud cases, this is not secretless: Sveltos holds a standing client_id/client_secret in a referenced Secret and exchanges it directly at the IdP's token endpoint. The resulting token feeds into the same cache, proactive-refresh, and auth-failure eviction machinery the other three providers already use.
PR: libsveltos #675

Smooth ClusterProfile/Profile Transitions (transitionFrom)
Moving a cluster between profiles via a label swap used to force a full undeploy-then-redeploy cycle: the old profile tore down everything it managed, including resources identical to what the new profile was about to deploy, before the new one could even start. A ClusterProfile/Profile can now declare, via transitionFrom, that it replaces one or more named predecessors: teardown of the predecessor is deferred until the successor reaches Provisioned on that cluster, and the successor may take over the predecessor's resources in place, ignoring tier restrictions. Support spans addon-controller (the core deferral/takeover logic), sveltos-applier (equivalent handling for pull-mode clusters), and new documentation.
PRs: addon-controller #1951, sveltos #787

🐞 Bug Fixes

addon-controller: RemoteURL Polling Interval Blocked Drift-Detection Recovery
A PolicyRef/KustomizationRef using RemoteURL with an Interval set NextReconcileTime on the ClusterSummary to schedule its periodic re-fetch, but that same field suppressed every other reconcile of that ClusterSummary until the cooldown expired, including one triggered by drift detection. With SyncMode: ContinuousWithDriftDetection and, say, a 10-minute RemoteURL interval, a configuration drift would sit unrecovered until that cooldown passed. NextReconcileTime is no longer set in this case.
PR: addon-controller #1929

ui-backend: Three Authentication and Authorization Bugs
/stats returned a 500 on a management cluster with no Cluster API installed; it now short-circuits to zero CAPI clusters when the CRD is absent. Every RBAC check (canListSveltosClusters, canGetClusterProfile, and similar) was sending the Kubernetes Kind as the SubjectAccessReview's resource field instead of the plural REST name RBAC rules actually use, so no real scoped ClusterRole could ever match, only a wildcard role like cluster-admin. And every SubjectAccessReview only ever set Spec.User, never Spec.Groups, so RBAC granted via a Group subject was silently denied regardless of what the role granted.
PR: ui-backend #181

dashboard: OIDC Login Rejected by Audience-Checking API Servers
The dashboard's OIDC login hardcoded its scope to openid profile email offline_access, requesting no specific resource. Providers that issue single-resource access tokens (Entra ID, notably) then audience the token to the dashboard's own app registration rather than the target API server, so

dashboard: OIDC Login Rejected by Audience-Checking API Servers
The dashboard's OIDC login hardcoded its scope to openid profile email offline_access, requesting no specific resource. Providers that issue single-resource access tokens (Entra ID, notably) then audience the token to the dashboard's own app registration rather than the target API server, so a Kubernetes API server that authorizes by audience (e.g. AKS with Microsoft Entra ID authorization) rejected it with "failed to validate token." A deployer can now set an optional VITE_OIDC_SCOPE/OIDC_SCOPE to request a resource-specific scope instead; unset, behavior is unchanged.
PR: dashboard #187

libsveltos: Drift Exclusion Crashed on a Path Absent From the Helm Render
Helm's PostRenderer fed driftExclusion patches straight to kustomize with no missing-path check, unlike drift evaluation's own path, which already treats a remove on an absent path as a no-op. A chart render missing the excluded path failed hard instead of skipping it. The PostRenderer path now filters patches the same way drift evaluation does before handing them to kustomize.
PR: libsveltos #673

addon-controller: ClusterSummary Status Update Could Lose a Race
updateStatusForNonReferencedHelmReleases did a single Get plus a single Status Update with no conflict retry, unlike its two siblings on the same pass. A concurrent status write could bump the ClusterSummary's resourceVersion in between, losing the update to a resource-version conflict even though the Helm deploy had already succeeded: the feature hash never advanced, the Helm feature kept reporting Failed, and drift-detection registration was never reached. Now wrapped in the same conflict-retry the other two call sites already use.
PR: addon-controller #1937

addon-controller: Silent ResourceSummary Removal Failures
A failure removing a ResourceSummary, in either prepareForDeployment or cleanupBeforeFinalizerRemoval, was only logged, never written to ClusterSummary.status. An ongoing failure was invisible to kubectl get clustersummary: status just sat wherever it last was, silently retrying every reconcile with no visible sign anything was wrong. Both call sites now surface the error via status.
PR: addon-controller #1947

libsveltos: Auth-Rejected Clients and Workload-Identity Tokens Not Evicted From Cache
A cached client or workload-identity token rejected server-side for a reason its own recorded expiry doesn't predict (early revocation, an IdP restart, a permissions change) kept being reused until whatever proactive refresh window applied eventually caught up. GetKubernetesRestConfig/GetKubernetesClient and the workload-identity path now both wrap the returned config's transport so any 401/403 response, from any client built off it, evicts the corresponding cache entry immediately instead of waiting on a schedule.
PRs: libsveltos #674, libsveltos #676

addon-controller: Deferred Teardown Not Reflected in ClusterSummary Status
When teardown was deferred by a still-existing DependsOn dependent or a TransitionFrom successor not yet Provisioned, ClusterSummary.status.featureSummaries[].status stayed on whatever it was before, implying active work even though nothing was happening. status.dependencies already explained the wait; status itself did not. A new Blocked FeatureStatus value now reflects it directly.
PR: addon-controller #1953

Stop Polling Reports From Pull-Mode Clusters With a Dead sveltos-applier
healthcheck-manager, event-manager, and classifier each kept listing HealthCheckReports/EventReports/polling a pull-mode cluster every collection cycle regardless of whether its sveltos-applier agent was still sending a heartbeat. A cluster whose agent has died will never produce a new report, so this work, and its retry cadence, ran indefinitely for nothing. All three now check the agent's heartbeat status first and skip a cluster whose sveltos-applier has gone stale.
PRs: healthcheck-manager #430, event-manager #517, classifier #507

🔧 Maintenance

• All components advanced to Go v1.27.1
• All components advanced to Cluster API v1.14.2

🚀 New Features

Job-Based Health Checks
ValidateHealth gains JobCheck, a third check type alongside the existing Lua Script and CEL evaluation: point it at a Job manifest (via JobRef, stored in a Secret or ConfigMap) and its Complete/Failed outcome becomes the check result, mutually exclusive with the other two. Since ValidateHealth is embedded by both ClusterProfile/Profile and ClusterPromotion, it's available to PreDeployChecks, ValidateHealths, PreDeleteChecks, PostDeleteChecks, and PostDelayHealthChecks with no further changes.
PRs: libsveltos #654, sveltos #775

Per-Resource Force Recreate
KustomizationRef.Force/PolicyRef.Force applied all-or-nothing to every resource in a reference. A single resource can now opt into force-recreate on its own by carrying the projectsveltos.io/forceRecreate annotation, even when the reference-level Force is false.
PR: libsveltos #655

Gzip-Compressed and bsdtar-Produced OCI RemoteURL Layers
RemoteURL's oci:// path had two gaps that caused real-world OCI artifacts to fail or get misread: a gzip-compressed tar layer failed the tar parse and fell through to the raw-blob path, so the compressed bytes were handed downstream as if they were YAML; and AppleDouble/PAX sidecar entries produced by tools like macOS's bsdtar (e.g. ._ns.yaml next to ns.yaml) were matched by extension alone and swept into the manifest as binary garbage. Both are now filtered and decompressed correctly.
PR: addon-controller #1911

RemoteURL Tarball Support and Insecure-Connection Options
PolicyRefs' remoteURL over HTTP/HTTPS now accepts a tarball of multiple YAMsed or plain), not just a single raw document. RemoteURL/RemoteKustomizeURLalso gain two optional fields: plainHTTP to connect to an OCI registry over plain HTTP, and insecureSkipTLSVerify to skip server certificate verification, matching the trust optalready available for Helm OCI registries.
PRs: sveltos #780, addon-controller #1913

⚙️ Improvements

Reduced CRD Watcher Memory Usage
WatchCustomResourceDefinition kept every CustomResourceDefinition on the cluster in a local indexed cache for the life of the process, even though every caller only reads the GVK carried by the event that fires and none of them ever read the cache back. It's now backed by a Reflector that forwards each event straight to the handler and discards it, keeping the same list-then-watch/relist-on-error behavior without the resident memory. Most visible on sveltos-agent, in clusters with many CRDs installed.
PR: libsveltos #659

Helm Drift Redeploy Scoped Per Chart
With syncMode: ContinuousWithDriftDetection deploying multiple Helm charts from one ClusterProfile, drift on a single resource used to mark the entire Helm feature for redeploy and unconditionally upgrade every chart, regardless of whether it had drifted or even changed. Redeploy now checks a per-chart flag first, so a chart that neither drifted nor changed is left alone.
PR: addon-controller #1915

sveltos-agent: Reduced ConfigMap Memory Usage in Agentless Mode
In agentless mode, sveltos-agent's cache already scoped ConfigMaps by cluster namespace, but cached every ConfigMap in that namespace in full, including unrelated Helm-values or raw-YAML ConfigMaps deployed via policyRefs. It's now filtered by name to just the ConfigMap relevant to that cluster.

🐞 Bug Fixes

addon-controller: DeploymentType Local Cleanup on a Self-Managed Cluster
When the managed cluster is a self-managed SveltosCluster (its remote client/config resolve back to the management cluster itself), the remote-cluster stale-resource cleanup pass scanned the management cluster with no per-ClusterSummary scoping, deleting same-GVK resources deployed there by other ClusterSummary instances via deploymentType: Local. Every deployed resource is now tagged with its owning ClusterSummary, and both cleanup passes honor that tag, checking it only as a protective signal so pre-upgrade resources without it still fall through to the existing ownership checks.
PR: addon-controller #1892

sveltos-agent: Watching GVKs From Other Clusters in Agentless Mode
The GVK-watch-building path for Reloaders, EventSources, and HealthChecks listed every instance in the management cluster instead of scoping to the managed cluster an agent instance is responsible for, so an agent could enable ConfigMap/Secret watches or start informers for kinds only relevant to a different cluster's policies. Now filtered against each cluster's own tracking ConfigMap, matching the scoping the reconcilers already applied.

addon-controller: Reloader Not Cleaned Up on ClusterProfile Delete
Deleting, or unmatching, a Helm-based ClusterProfile with spec.reloader: true left its Reloader instance, and in agentless mode its per-cluster ConfigMap entry, behind indefinitely, referencing Deployments from a chart no longer deployed. The undeploy path was tagging the cleanup with the Kustomize feature instead of Helm, so both lookups silently missed. Resources- and Kustomize-based profiles were unaffected.
PR: addon-controller #1898

healthcheck-manager: Stale ClusterHealthCheck Conditions and Notifications
Three compounding bugs kept Status.Conditions and notifications frozen even as the underlying HealthCheckReport kept updating: Spec.HealthCheckName was never populated on HealthCheckReport, the watch mapper relied on that same empty field and resolved to zero ClusterHealthChecks to reconcile, and re-evaluation was skipped for clusters already Provisioned. Also fixes related Discord/Slack formatting bugs.
PR: healthcheck-manager #421

addon-controller: Failed Helm Upgrade Could Silently Uninstall the Release
A failed Helm upgrade still leaves a release record behind, stamped with the version it tried, and failed, to reach. That made the install/upgrade decision misread the release as already handled, and after a couple more failures deleted it and reinstalled from scratch. The decision now checks whether a release exists at all instead of inferring it from version/status, and the install-retry threshold is now its own setting, HelmInstallOptions.RecoverAfterConsecutiveFailures (default 5), instead of being borrowed from Helm's revision-retention MaxHistory.
PR: addon-controller #1912

addon-controller: Four ClusterSummary Reconcile Bugs
A transient, non-NotFound error checking whether a cluster still exists was treated as "cluster present," which could stall a ClusterSummary in Terminating indefinitely. One cluster's stale ResourceSummary cleanup could be blocked by an unrelated cluster's same-named ResourceSummary. Helm chart downloads via LocateChart had no timeout and could wedge a deployer worker permanently. And deletion didn't honor dependsOn ordering, letting a prerequisite and its dependent undeploy concurrently in any order.
PR: addon-controller #1918

Expired Kubeconfig Tokens Not Evicted From Cache
An expired token only surfaces on first actual use of a cached client, not when the client is built, so classifier, event-manager, and healthcheck-manager kept retrying the same stale credentials indefinitely. The client is now evicted from cache on an auth error so the next cycle rebuilds it from a freshly read kubeconfig Secret.
PRs: event-manager #512, classifier #500, healthcheck-manager #424

healthcheck-manager: Notification Events Truncated to Kubernetes' Limit
Notification Event messages could exceed the 1024-character limit Kubernetes enforces on Event messages; they're now truncated to fit.
PR: healthcheck-manager #425

🔧 Maintenance

• All components advanced to Cluster API v1.14.0
• All components advanced to Go 1.26.6