Skip to content
Docs · Documentation

Clusters

Production and read-only

Guard rails for clusters you can't afford to break.

Two per-context switches add safety. Set them in the Clusters & Kubeconfigs tab or in settings.json under kubernetes.contexts.<cluster-id>.

Production cluster

The cluster shows a red PROD badge in the title bar and sidebar. Destructive actions ask you to type the object's name to confirm: Delete, Kill, Drain and Undo rollout, plus Cordon, Uncordon and Scale from a list or the palette. Applying YAML asks for confirmation too, unless you set yaml_editor.confirm_apply_on_prod to false.

Read-only mode

Mutating actions are unavailable and mutating requests are blocked. That covers editing and applying, scaling, deleting and restarting, and also features that run code in the cluster:

  • Exec, attach, debug containers and node shell.
  • Port-forwarding and the file browser.
  • Creating silences in alerts.
  • Saved and auto-start port-forwards, which are checked again when they start.
  • Every Helm write (install, upgrade, roll back, uninstall) and every Flux action. On read-only clusters the Helm install flow offers the command to copy instead.
  • Argo CD sync, refresh and delete actions, and cluster update starts in Cluster updates.

Reading is unaffected. Service web views are allowed on read-only clusters because they only read.

Helm, Flux, agents and the local terminal

  • Helm and Flux: on a production cluster every write asks for confirmation, and Helm's dialogs and Flux's Delete need you to type the cluster or object name.
  • AI agents only have read tools, so they work on read-only clusters. Write tools do not exist yet, and when they do they will be hidden on read-only clusters. The agent's cluster_info tool tells it whether a cluster is PROD or read-only. See AI agents.
  • Local terminal: a local shell is your own kubectl on your machine, so neither read-only mode nor production confirmations restrict what you type in it. Kubyl shows a "local · not protected" chip, and on a production cluster you must type the cluster's name before the tab opens. Available in the release after 0.6.0.

Permission checks

Independent of those switches, each action runs a SelfSubjectAccessReview first, so actions your RBAC forbids are disabled instead of failing halfway. The checks are repeated after a reconnect or a failed check, and a cluster keeps its PROD and read-only flags while it is disconnected.

Bulk actions

Actions on a multi-selection report the items they skipped, for example because of RBAC or read-only mode. When the selection spans several clusters, as in a favorites workspace, read-only, RBAC and PROD are checked for each cluster separately.

Something missing or wrong? Open an issue on GitHub.