Fleet drift detection without a control plane

Multi-cluster platform work rarely happens one cluster at a time. This is how conndeck approaches fleet drift from a local desktop tool, without putting a hosted control plane in the middle.

What fleet drift is and why it hurts

Most fleets contain clusters that are supposed to be identical: staging and prod, or the same service across regions. Fleet drift is their slow divergence from each other, and it rarely comes from a deliberate decision. A kubectl patch applied during an incident never gets backported. A Helm release is upgraded in one region and not the others. A fix goes straight to prod under time pressure and staging never receives it. Each change is small and justifiable; the accumulated difference is not.

The cost is lost confidence. Staging stops being evidence about prod: a change that validates there can still fail in production because production is quietly different. Rollbacks stop being symmetric. Incident response slows exactly when speed matters, because the mental model says the clusters match and the API says otherwise. For anyone with audit obligations, "are these environments the same" becomes unanswerable without a way to compare them.

The control plane answer and its cost

One common answer is a hosted control plane: some fleet-management systems use agents in each cluster that report to a central backend, with a dashboard aggregating the fleet. For some teams this is the right trade, but the aggregation point concentrates risk, and the costs are structural.

Credentials and reachability. The backend or its agents need API access to every cluster, including production. Depending on the architecture, cluster metadata or operational data may cross your network boundary.
Blast radius. Central aggregation can increase the sensitivity of the data held by that service, depending on what it collects about your topology, versions, and workloads.
Review burden. New hosted data flows may require additional security and data-governance review. A vendor backend holding production cluster state is a significant, recurring one.
Another system to run. Self-hosting avoids the vendor but adds infrastructure to patch, back up, and secure.

Reading clusters directly

conndeck's premise is that the aggregation can happen on the operator's machine instead. It is designed around a local-first Rust Kubernetes core — the same core powers both the GUI and the TUI surfaces — with kubeconfig discovery that follows kubectl's resolution order. Credentials such as tokens, certificates, client keys, and exec-env data are handled inside the core and are not exposed to the Svelte webview, which is not given broad filesystem, shell, or HTTP capabilities. The product direction is to keep multi-cluster operations, including aggregate views, local by default and free of any hosted-account requirement.

This only works if it stays fast, so performance is treated as a product feature: budgets are source-backed and enforced in CI. Named budgets include "Query 10k Pods", "Search-filter 10k Pods", and "Aggregate Pod view".

One thing to be explicit about: conndeck is pre-release, and the fleet features below — drift compare and the promote flow — are product direction, not shipped functionality. The current design direction follows.

Drift compare, conceptually

Drift compare is meant to answer a narrow question: what differs between clusters that are supposed to match. The intended scope is narrow.

The roadmap direction is to compare selected cluster contexts — for example, a staging and a production cluster that are expected to be identical.
The comparison is intended to be presented locally, using the operator's existing cluster access rather than a separate hosted account.
The intended approach is local-first: cluster data stays on the device by default unless the user explicitly enables a sync or sharing workflow.

Guarded promote, as direction

Detection is half the problem; reconciliation is the other half. The promote flow is conndeck's roadmap direction for the write path: moving what runs in one environment toward another, under guardrails.

The guardrail model is not specific to promote. Destructive actions across the tool are gated rather than free-form, and any future promote write path is intended to follow the same guarded-action principle. This is roadmap, presented as direction, not as something you can run today.

Why no control plane is a security feature

The missing control plane removes a category of risk rather than adding a capability.

Local data by default. Kubeconfigs, credentials, logs, events, and YAML stay on the user's device by default, unless the user explicitly enables a sync or sharing workflow. No hosted account is required to inspect your own clusters.
Smaller review surface. A local-first architecture can reduce the hosted data flows that require review. See the security threat model for the published security posture.
Hostile-input posture. Logs, annotations, events, YAML, and CRD schemas are treated as untrusted input, even when they come from your own fleet — a compromised cluster should not become a path into the operator's machine.
Verifiable releases. Release verification is part of the design: signed builds with SHA256 hashes, detached signatures, an SBOM, and provenance metadata, plus a copy-paste verification command.
No hosted dependency for inspection. The design goal is for routine local cluster inspection not to require a hosted account.

Trade-offs

Trade-offs include:

Comparison, not enforcement. The current roadmap discussion focuses on local drift comparison. Continuous enforcement — reconciling drift automatically or alerting on it — belongs to in-cluster GitOps or policy agents.
Local by default. Cluster data stays on the device unless the user explicitly enables a sync or sharing workflow, so sharing results with a colleague is a deliberate step rather than a side effect of a common account.
Local environment bounds. Local-first fleet operations necessarily depend on the operator's local environment and authorized cluster access.
Pre-release status. Public artifacts are not yet shipping, and drift compare and promote are roadmap direction; today they are designs to evaluate, not tools to run.

Whether these trade-offs are acceptable depends on your fleet size and threat model. For a look at how this local-first posture compares with a desktop alternative, see the conndeck vs Lens comparison.