One core, two surfaces: GUI and TUI for Kubernetes ops

Kubernetes operators often move between graphical and terminal-based tools for related tasks: a graphical surface for looking, a terminal for doing. conndeck's premise is that this split is optional — one Rust Kubernetes core is designed to drive both a desktop GUI and a TUI, so the two surfaces can behave as one tool.

The two-tool tax

The split is so normal it is easy to miss the cost. A desktop dashboard for browsing during the day; a terminal during an incident. Each is reasonable on its own. The tax shows up between them.

Two mental models. Navigation, naming, and object-state presentation differ between tools, so knowledge built in one does not fully transfer to the other.
Muscle memory that expires at the boundary. The workflow practiced all day in a GUI may not be available at 03:00 in a terminal; you rehearse one tool and get paged into another.
Behavioral drift. Separate tools can implement destructive-action guardrails differently — delete flows, confirmation steps, and defaults — and those differences tend to surface under pressure.
Two review surfaces. Security review covers two codebases and two credential-handling paths rather than one shared implementation.

One potential cost is on-call speed. Incidents already force enough context switches between clusters, namespaces, and logs; adding a tool and mental-model switch at the moment you move from looking to acting can add avoidable latency during an incident.

One core, two surfaces

conndeck's architecture starts from a Rust Kubernetes core. The desktop GUI is a Tauri shell with a Svelte front end; the TUI is a terminal front end. The same Rust core powers both surfaces, and it is intended to keep cluster behavior consistent across them: behavior implemented in the core has one implementation rather than two.

The shared behavior the surfaces are designed to sit on includes:

kubeconfig discovery, following the same resolution order as kubectl, so context handling stays familiar and auditable against the standard toolchain
credential handling, where tokens, certificates, client keys, and exec-environment data are not exposed to the webview layer
the read path: cluster browsing, workload inspection, streaming logs, RBAC context, and network context
the write path: guarded actions, where destructive operations are gated, and guarded apply for changes

The GUI and TUI provide different interaction models over that shared behavior — layout, mouse versus keyboard, how a list is drawn. Performance is treated with the same product discipline: budgets are source-backed and enforced by CI, with named budgets including "Query 10k Pods" and "Search-filter 10k Pods".

conndeck is pre-release, so read this as the architecture and what it is designed to make possible, not as a feature matrix you can download today.

When the GUI wins

The graphical surface is designed to earn its place when the problem is orientation.

Exploration. Some operators find rendered views of workload relationships, RBAC context, and network context easier to scan than text when orienting in an unfamiliar cluster.
Onboarding. Navigating by recognition rather than recall can lower the barrier for a new team member who does not yet know the territory.
Dense state. Aggregate views and large filtered lists are cases where a visual layout can compress what a terminal would paginate.

When the TUI wins

The terminal surface is designed for speed under constraint.

On-call over SSH. A jump host has no display server, so the intended TUI workflow is designed to work at the end of an SSH session, without a desktop in the middle.
Practiced speed. Keyboard-driven navigation keeps your hands where the rest of the incident toolkit — shells, editors, version control — already lives, with no round trip to the mouse.
Constrained environments. Low-bandwidth links and locked-down machines are terminal-native territory.

Because the TUI sits on the same core, the design goal is that it is not the lesser tool you tolerate at 03:00: the shared core is intended to keep cluster behavior and guardrails consistent across both surfaces.

Guarded actions that stay guarded

The consistency argument matters most on the write path. In a two-tool setup, safety behavior can drift: one tool tightens a destructive-action gate and the other picks it up a release later, or not at all. A shared core can reduce drift in the behavior it implements centrally. conndeck's guarded actions — gating destructive operations through shared guardrails, with guarded apply for changes — are designed as shared behavior in the core that powers both surfaces, so centralizing them is intended to reduce divergence between the GUI and the TUI.

The same intent holds for the security boundary. Credentials are handled locally and not exposed to the webview, the Svelte webview is designed without broad filesystem, shell, or HTTP capabilities, and hostile cluster data — logs, annotations, YAML, events, and CRD schemas — is treated as untrusted input across the security model. The protections are designed not to depend on which surface you happen to drive. See the threat model for conndeck's security approach.

Who benefits

On-call engineers, because the design goal is that the tool practiced during the day is the one reached at 03:00 — the same core behavior and guardrails, through a desktop or an SSH session.
Platform teams, because one tool means one workflow to document, teach, and keep current, and muscle memory transfers between surfaces instead of expiring at the boundary.
Security reviewers, because the shared Rust core can centralize review of cluster access and credential handling — though each surface still needs assessment on its own.
New operators, because the GUI is a place to learn the cluster and the TUI a place to grow into, with less relearning between them.

One core and two surfaces is a design choice about where behavior lives: in a shared layer that can be reviewed centrally and reused across both surfaces, rather than reimplemented in whichever window happens to be open. See the quickstart for introductory documentation.