v1.9.0
🚀 New Features
Remote URL Support in PolicyRefs
Reference YAML content directly from HTTP/HTTPS endpoints: Previously, PolicyRef was limited to ConfigMaps and Secrets, which imposed an ~1 MB size cap. You can now define a remoteURL field pointing to any HTTP/HTTPS URL. Sveltos fetches and redeploys automatically whenever the content changes, driven by a configurable polling interval (default: 5 minutes).
Optional authentication via secretRef (token, username/password, or CA file) and Go template rendering are fully supported.
preDeployChecks
Gate deployments on cluster readiness: A new preDeployChecks field on ClusterProfile/Profile lets you define conditions that must pass before Sveltos deploys any resource. This provides a built-in operational gate — for example, blocking rollouts until a cluster reaches a healthy state.
Avoid Spurious Helm Upgrades
Stable revision counters after management cluster takeover: When a new management cluster reconciled clusters that already had Helm charts deployed, the absence of stored state caused Sveltos to run helm upgrade on every reconcile even when nothing had changed. Revision counters now remain stable on takeover. Charts with patches: configured and
ContinuousWithDriftDetection subsequent reconciliations are intentionally unaffected.
Show Addons: Filter by Helm Charts or Resources
Targeted addon inspection in sveltosctl: sveltosctl show addons gains two new flags — --helm-charts to display only Helm releases and --resources to display only Kubernetes resources. This makes it easier to inspect large deployments without noise from unrelated resource types.
PR: sveltosctl #427
Dashboard DryRun Information
Simulation results in the Sveltos dashboard: The Sveltos dashboard now surfaces DryRun simulation results. Operators can review exactly what changes would be applied to each cluster before committing a profile to active mode — without leaving the dashboard.
🐞 Bug Fixes
Drift Detection and KustomizationRefs
Configuration drift for KustomizationRef-deployed resources was not being detected or repaired. Resources deployed via KustomizationRefs (e.g. through a Flux GitRepository) are now correctly tracked by the drift-detection agent and reconciled when changed out-of-band.
Helm Chart Errors in Pull Mode
Partial ConfigurationBundle instances no longer reach the applier: When processing Helm charts in pull mode, an error mid-flight could cause a partially populated ConfigurationBundle to be committed. The applier would then treat missing resources as deleted, pruning live workloads or deploying broken stacks. Bundle preparation is now atomic — any error discards all
partial state before it can be committed.
ClusterPromotion/ClusterProfile Ordering
When ClusterPromotion creates ClusterProfile resources, the order of HelmCharts, KustomizationRefs, and PolicyRefs must be preserved. A bug was causing the order in generated ClusterProfile resources to diverge from the ClusterPromotion definition. This is now fixed.
EventTrigger: Stale Profiles on EventSource Change
When an EventTrigger's referenced EventSource was updated, the ClusterProfile, ConfigMap, and Secret resources created for the previous EventSource were left as stale orphans in the management cluster. These are now correctly cleaned up whenever the EventSource reference changes.
DryRun: ClusterSummary Preserved When Cluster Stops Matching
When a ClusterProfile simultaneously changed its cluster selector (deselecting a cluster) and switched to DryRun mode, the system immediately deleted the ClusterSummary and ran undeploy logic — leaving no ClusterReport behind. Sveltos now keeps the ClusterSummary alive in DryRun scenarios, generates a ClusterReport for the diff, and defers actual cleanup until
DryRun mode is exited.
Shard Controller: Cluster Shard Tracking
The shard controller was building its internal cluster map key from an uninitialized object (before the Get call), so every reconcile wrote to the same empty namespace/name key, corrupting the cluster-to-shard map. Cluster shard tracking now correctly identifies clusters by their actual namespace and name.
ClusterConfiguration OwnerReference Updates
Incorrect logic when updating ClusterConfiguration ownerReferences was causing instances to be erroneously deleted. This is now fixed.
🤖 MCP Server Tools
list_pending_profiles_for_cluster
Identify why a profile update is blocked: Given a cluster reference, this new tool scans all ClusterProfile and Profile resources and returns those whose update to that cluster is currently pending, together with a structured reason. Two reasons are surfaced: ClusterSuspended (the cluster is paused or outside its active window) and MaxUpdateThrottle (the cluster is
queued behind others under a MaxUpdate limit).
PR: mcp-server #47
list_dryrun_changes_for_cluster
Preview changes before they apply: This tool surfaces the simulated changes that DryRun-mode profiles would apply to a given managed cluster. Results are organized across three categories — Helm release changes, resource changes (from policy refs or pull-mode templates), and Kustomize changes — with no-op entries suppressed for clarity. Each result also includes a
hasChanges summary flag.
PR: mcp-server #48
⚡ Optimizations
ResourceSummary Collection
Unnecessary network calls to managed clusters to check or remove ResourceSummary instances are now skipped when the sync mode is not ContinuousWithDriftDetection and no ResourceSummary was ever deployed. This eliminates spurious reconcile failures and 10-second retry loops against unreachable clusters.
PRs: addon-controller #1735, #1750
Report Collection at Scale (Agentless Mode)
EventReport, HealthCheckReport, ReloaderReport, and ClassifierReport collection in agentless mode has been optimized across event-manager, healthcheck-manager, and classifier. All reports are now fetched in a single management-cluster query instead of one query per managed cluster. Collection is also skipped entirely for clusters with no matching EventTrigger,
ClusterHealthCheck, or reloader-enabled profile. In environments with more than 50 clusters, up to 5 parallel workers are used to parallelise report processing.
PRs: event-manager #475, healthcheck-manager #398, classifier #465