Apps, GitOps and operators

Every tool here is shown only when your server has it and (for Argo CD, Flux and Helm) your cluster does. All writes use the two-step sheet.

The Apps hub (next release)#

The Apps tab becomes a 2x2 hub of cards: Argo CD, Flux, Helm and Workloads, each with a live status line. A greyed card says why: Update your Kubyl server (capability missing), Not installed on this cluster, or No permission. The released app (1.0.2) opens straight into the Argo CD list and keeps Helm under More. The Workloads card shows ready counts per kind, the workloads that are not ready and a way into each kind's table (grouping by app label is not possible yet).

Argo CD#

• Applications: filter chips for project, destination, sync (Synced, OutOfSync, Unknown) and health (Healthy, Progressing, Degraded, Suspended, Missing, Unknown) with counts, a text filter, a sort sheet, auto-sync wording, the last result and a live “Syncing 12/40” chip. Counts of out-of-sync and degraded applications sit in the header.
• Application page: Summary, Resources (tree and list with a node sheet), Diff, History, Events and Controller logs. The Resources tab opens the object screens; controller logs reuse the log viewer on the controller's pods.
• Actions: the sync sheet (revisions, the resources that differ, Prune, Apply out-of-sync only, Dry run, Force, Replace, server-side apply, selective sync and a sync-window warning), Refresh and Hard refresh, Rollback (pick a history entry, compare, optionally turn off auto-sync), Terminate, policy toggles and Delete (three cascade options, the application's name typed). ApplicationSets and Projects have lists and pages.
• Kubernetes mode and API mode. By default the server reads and patches the Application objects with the cluster's own RBAC, no Argo CD login. A header chip (“Kubernetes mode”, “API · sign in”, “API · name”) offers signing in to Argo CD (password, token, or SSO through the browser). In API mode you also get desktop-style desired-versus-live diffs, the full resource tree and actions under Argo CD's RBAC. The server keeps the session; it is never shown. Only a unified diff is available, not side by side.
• “Open Argo CD UI” opens the install's URL in the browser. A “managed by Argo CD” note on object pages is not there yet.

Flux CD (next release)#

• Overview: health headline, four groups (Sources, Kustomizations & HelmReleases, Notifications, Image automation) with counts, per-kind counts, Needs attention and the controllers with versions. It says so when it cannot list the controllers' Deployments.
• Lists: by category and by kind, failing first, with state chips and counts, a namespace chip and a text filter. A state the app does not know is shown as “other” with the server's label.
• Object page: facts, conditions, what it is waiting for, managed by (tap to open), dependencies and dependents, an inventory with health tones (the first 50, then all, tap to open), history and references by name. It names referenced ConfigMaps and Secrets and never shows their content, Helm values or postBuild substitutions; URLs lose their credentials.
• Actions (need the server's actions.flux; hidden on read-only clusters): Reconcile, Reconcile with source (waits up to two minutes for the source controller), Suspend, Resume, Delete (asks for the object's name and says what the controller will remove), and for a HelmRelease Force upgrade and Reset failures, offered only when the object can use them.
• Flux's recent activity and controller logs are not on the object page yet.

Helm#

Releases are grouped by namespace with status chips and a namespace chip (All namespaces needs list on Secrets cluster-wide). A release page has Overview, Values (User-supplied or All with chart defaults), Manifest, Notes, History (chart, app version, description, older and newer revisions), Resources (they open their object screens) and the exact helm commands to copy. Values and manifests are masked; Reveal shows values after Face ID or your passcode, never keeps them, and hides again on Mask or when you switch revision.

Install, upgrade, rollback, uninstall (next release)#

Needs a server with a usable helm (3.13 or newer) and no helm_writes: false; see What the mobile client can and cannot do. The buttons are hidden on read-only clusters. If the server's Helm is missing, too old or broken a banner (“Helm changes are off: …”) replaces them.

• Install: the + on the Helm page. Search charts in the added repositories, or type repo/name or an oci:// reference. The chart page shows its README (plain text), values.yaml, about and a version picker. The form has release name, namespace, create namespace, a monospace YAML editor (with “Chart defaults” to view or copy in) and options: wait, atomic, skip CRDs, timeout. Review is the standard sheet: dry-run problems (a values schema refusing your values shows here), created, changed and removed objects (+, ~, -, = kept), hooks apart, CRD notes (“installed once, never upgraded or deleted by Helm”) and a values diff.
• Upgrade: pick the chart (Helm does not record a release's repository, so the app guesses by chart name or you type a reference), the version, the values and Keep current values (reuse values). Masked values are not sent back: entries shown as masked keep the cluster's value. A masked entry inside a list or block cannot be preserved safely, so the review waits until you reveal the values.
• Rollback: pick a revision from the history. Uninstall: shows the objects that go (hooks apart) and what stays, with keep history, skip hooks and wait; it asks for the release's name.
• Progress: after you confirm, Helm's output streams in; Stop (asks first, needs the server's actions.cancel) interrupts it, and the result links to the new revision. One write per release at a time; if the release changed since you reviewed, review again.
• Repositories: list, add (a name and an http(s) URL; no credentials can be sent), remove (asks) and update one or all. They are shared by every device on the server; add private ones on the server yourself.

Operators (OLM)#

• Sub-tabs: Installed, Install plans (grouped: waiting, installing and failed, complete), Subscriptions and, with OLM v1, Extensions and ClusterCatalogs (read-only).
• Operator page: status, deprecation note, an upgrade card with a review summary, Approve… and Review changes (CRDs with diffs, other steps, RBAC, compatibility notes and problems), provided APIs, the subscription, the CSV YAML and Uninstall… (CRDs and instances on request, name typed).
• OperatorHub: server-side parsed catalogs with search, sort, filters (category, capability, provider, catalog, installed only), paging and a package page. Install asks for channel, version, install mode, namespace and approval; Prepare lists what will be created.
• Not yet: creating instances from alm-examples, instance counts, package icons (letter tiles instead) and a “New ClusterExtension” template.

Cluster updates#

Cards in the desktop's order: provider notes (with copyable commands), the version card (platform, cluster id, support, channel, status), the update path with selectable targets, risks, pre-flight checks (problems first, passed ones folded, with fixes) and cluster operators, node pools and add-ons. Update to {version}… is gated: pre-flight finished, “I've read the results”, each risk ticked, the undo text read, and the cluster name on PROD. The page polls (every 15 s idle, 5 s while updating). Updates that the server can start (OpenShift, k3s, Cluster API and the like) are written but have only been exercised against a self-managed test cluster, where they are refused. EKS, GKE and AKS stay on the Kubernetes-side view because the server has no cloud credentials.