What the mobile client can and cannot do

Can#

• Browse every cluster and resource type with live tables, and open objects as JSON or YAML.
• Read logs (follow, previous, since), open a shell in a pod or on a node, and use pod files.
• See metrics and Prometheus charts, alerts and silences.
• Argo CD applications (sync, rollback, refresh).
• Flux CD objects (Kustomizations, HelmReleases, sources, notifications and image automation with their inventory, dependencies and history; reconcile, suspend, resume, force, reset and delete).
• Helm releases: read, and with the server's helm install, upgrade, rollback, uninstall, chart search and repositories (next release).
• OLM operators and upgrade approvals, and what each cluster runs and could be updated to.
• Describe and related objects, port-forward and web views through a one-time address.
• Make changes: delete (force kill for pods), scale, rollout restart, undo and pause, cordon and drain, CronJob run and suspend, debug containers, YAML apply with a dry-run diff, Argo CD sync, rollback, terminate, policy and delete, Flux actions, OLM operator install, approve and uninstall, and cluster updates where the server supports the provider.
• Open a shell on a node (a privileged helper pod), and with Argo CD API mode get desired-versus-live diffs and the full resource tree.
• Sign in to OIDC and OpenShift clusters (device code, browser, password or token) and let the server keep the refresh token.
• Chat with AI agents that run on the server (read-only, next release).

Cannot#

• See Secret values by default: they are masked in objects, YAML and manifests. You can reveal single values on purpose (device lock, rate-limited and audited), but Secrets cannot be applied or edited from the phone.
• Port-forward raw TCP ports, or give several people separate identities on the Personal plan: there is one user per server.
• Write to a cluster through an AI agent: agents are read-only.

Every change is two steps#

Prepare shows what would happen, confirm applies it. The server enforces your rules: a cluster marked read-only refuses writes, and on a production cluster confirming needs the cluster's name typed in. Set both per cluster in settings.json with kubernetes.contexts.<cluster id>.read_only and .production. The cluster id is the context name, followed by @ and the kubeconfig's path for contexts from a file (for example my-context@/kube/config). The setting is the same for every device and needs a restart. What this looks like on the phone: Safe changes.

{
  "kubernetes": {
    "contexts": {
      "<cluster id>": { "production": true, "read_only": false }
    }
  }
}

Flux CD (next release)#

The server lists the Flux custom resources the cluster serves (each kind on its own, at the version the cluster prefers) and reads them with the signed-in user's own access. An object's details name the ConfigMaps and Secrets it references and never their content, Helm values or postBuild substitution values; URLs lose their credentials. Deleting a Kustomization or HelmRelease asks for its name and says what the controller will remove; suspend and force upgrade are marked as changes that need a second look. “Reconcile with source” waits up to two minutes for the source's controller, like flux reconcile --with-source.

Helm writes (next release)#

Helm writes are listed as capabilities only while the server has a usable helm (3.13 or newer). The image ships a pinned helm; outside the image put your own in the server's PATH or name it in settings.json ("helm": {"path": "/usr/local/bin/helm"}; the section also takes default_timeout and atomic). The server never downloads one, and looks again for a missing helm when a client asks, so installing it needs no restart.

• Switch. server.helm_writes: false (or --helm-writes=false, KUBYL_SERVER_HELM_WRITES=false, chart value helm.writes: false) turns it all off: no capability, and every Helm write, repository and chart call answers FAILED_PRECONDITION with a message saying so.
• Files. Helm's repositories, caches and data live in <config dir>/helm/{config,cache,data} (mode 0700; /config/helm/... in the image). The server refuses a helm that uses other directories. The repository list is shared by all devices. The app can add a repository by name and an http(s) URL only: no user name, password, certificate or --insecure setting can be sent, and registry logins do not exist. Add repositories that need credentials yourself with the server's helm (HELM_CONFIG_HOME=... helm repo add --username ...). Charts come from an added repository or an oci:// reference (no credentials in it); Artifact Hub is never used.
• Egress. The server must reach the chart repositories and OCI registries your devices use, and the cluster API. A paired device can make it fetch any http(s) address by adding a repository, so pair only devices you trust (they already hold your clusters' access).
• Credentials. Each write runs helm against the file that defines the cluster and its context. For sign-ins Kubyl manages (OIDC, OpenShift) the token goes into the child's environment only, never into arguments or files. With per-device sign-ins each device's helm runs with that device's own token. Values go to helm on stdin and are shown masked in the preview. Nothing helm prints on stdout, no values and no tokens are logged; the audit log has the caller, cluster, release, chart, version and outcome.
• Two steps. Prepare runs a server-side dry run (client-side if the cluster refuses that) and lists created, changed and removed objects, hooks, CRDs and the values diff. Confirm starts the write and the app follows it; a running write can be cancelled (Helm records the release's state). Read-only clusters refuse, production asks for the cluster's name, uninstall asks for the release's name. One write per release at a time; a release that changed between the steps must be prepared again.