Why local-first matters for Kubernetes tooling
Some Kubernetes workflows depend on hosted accounts or browser-based control planes. conndeck is designed around the opposite premise: a tool that administers production infrastructure should not require a vendor-hosted control plane to do its job.
conndeck is currently pre-release. The architecture described here reflects its design and launch requirements; public download artifacts have not yet shipped.
What local-first actually means
Local-first gets used loosely, so it is worth defining concretely. In conndeck's architecture it reduces to three properties that hold by default, not by configuration:
- No telemetry.
- No login. There is no hosted account between you and your clusters; the identity that matters is the one already in your kubeconfig.
- Cluster data stays on the device by default. kubeconfigs, credentials, logs, events, and YAML remain on the machine unless you explicitly enable a sync or sharing workflow.
The mechanism behind this is a Rust Kubernetes core that runs on the device. The same core powers both the desktop GUI — a Tauri shell with a Svelte front end — and the TUI, so the posture is not a property of one surface but of the layer all surfaces share. The positioning line is a literal statement of the design goal: "Fast, secure Kubernetes GUI. No telemetry. No login. No data leaves your device."
The threat surface of telemetry
Telemetry in a cluster operations tool is not the same category of thing as telemetry in a text editor. Cluster metadata, logs, events, YAML, and credentials are sensitive inputs, and whatever service a tool reports to becomes part of the data flow around production infrastructure. conndeck's local-first approach is designed to avoid sending that data to a vendor telemetry or account service by default.
The question in a security review is not whether a particular vendor is honest today; it is whether a third party's continued honesty should be a permanent dependency of your cluster operations. In environments with strict data-flow controls, avoiding vendor-hosted telemetry can reduce the number of external systems that teams must assess. A tool with no vendor telemetry limits intended network activity to cluster connections and any explicitly enabled sync or sharing workflows.
What stays on the device
Local-first only means something if the boundary is enforced in the architecture rather than promised in a policy. Three mechanisms are designed to do that work in conndeck.
Credentials follow kubectl's rules
Kubeconfig discovery follows the same resolution order as kubectl, so behavior is predictable to anyone who already knows the toolchain and auditable against it. Tokens, certificates, client keys, and exec-environment data are handled inside the Rust core and are not exposed to the webview layer.
The webview is not a privileged shell
Desktop apps built on webviews often grant the UI broad filesystem, shell, and HTTP capabilities, which can increase the impact of a webview vulnerability. conndeck's architecture is designed to deny the Svelte webview those capabilities. Just as important, cluster data itself is treated as hostile input: logs, annotations, events, and CRD schemas are parsed as untrusted, because a compromised or malicious cluster should not be able to reach through the tool into the operator's machine. See the threat model for the project's security framing.
A static site with no account system
The posture extends to the website. The site is static and has no cart or account system; checkout for paid tiers is handled by an external merchant of record. See the privacy policy.
The trade-offs
Local-first is a default, not a dogma, and it costs real convenience:
- No ambient multi-device state. Local-first defaults do not assume a hosted account for carrying cluster data between devices.
- No passive sharing. Sharing is framed as an explicit workflow rather than a default data flow.
- Verification over trust. The release process is designed to be verifiable — signed builds, SHA256 hashes, detached signatures, an SBOM, provenance metadata, and a copy-paste verification script are planned launch requirements — and the model assumes you would rather verify than trust.
The product direction treats any sync or sharing workflow as an explicit opt-in. The boundary of what leaves the device is intended to be a decision the user makes, with defaults that err toward keeping data on the device. That is a worse fit for teams who want zero-configuration fleet-wide dashboards, and a better fit for teams who want to account for what their tools transmit.
Who should care
- Security reviewers scoping a tool's blast radius before it touches production credentials. A local-first architecture can reduce dependence on vendor-hosted runtime infrastructure, while the binary, release provenance, cluster connections, and any enabled sharing workflows still require review.
- Teams evaluating tools for environments with strict outbound-data controls, where reducing vendor-hosted data flows simplifies assessment.
- Operators who care about latency. A local core is designed to talk to the cluster API directly, without a hosted control plane adding a round trip between you and your pod list. conndeck treats performance as a product feature, with source-backed budgets enforced in CI — named budgets include "Query 10k Pods" and "Search-filter 10k Pods".
- Anyone whose threat model includes the vendor. A local-first runtime can reduce the cluster data exposed through a vendor-hosted control plane, but release and supply-chain integrity still matter.
Local-first is not the only way to build a cluster GUI, but for tools that administer production Kubernetes it provides a useful default for reducing dependence on vendor-hosted runtime infrastructure. The planned launch requirements include credential isolation, restricted webview capabilities, untrusted-input handling, and verifiable release artifacts. See the security posture page for additional security information.