llms.txt

Helm Lifecycle

End-to-end Helm management — repos, charts, installs, upgrades, rollbacks, and live release status — without leaving the studio.

Overview

Bosca's Helm support drives the official helm binary as a subprocess on the controller side. We shell out rather than embed a Go SDK port: helm is the reference implementation of the chart template engine, hook handling, and release format, and tracking it in-process introduces subtle incompatibilities at every release.

The studio surfaces the lifecycle in three views: Releases (everything installed across namespaces), Catalog (charts across configured repos), and Repos (manage the repos themselves).

Helm Repositories

Add a repo via Kubernetes → Helm → Repos → Add repo. Bosca validates the repo at register time by fetching its index.yaml — a failed fetch surfaces inline and the repo is not persisted. Once registered, the controller refreshes the index on demand via the helmRepoUpdate mutation.

Repos are stored in the controller's kubernetes.helm_repo Postgres table — not in the helm CLI's ~/.config/helm/repositories.yaml. When the controller runs helm install, it resolves the chart via helm install <chart> --repo <url> so the CLI doesn't need a separate registration step.

Installing a Chart

The install wizard at Helm → Catalog → Install walks through:

  1. Pick a chart from a configured repo.
  2. Pick a version (defaults to the latest in the index).
  3. Pick a target cluster, namespace, and release name. Optionally create the namespace if it doesn't exist.
  4. Edit values in a YAML editor. The default values from the chart are pre-loaded.
  5. Optionally run a dry-run first — the controller passes --dry-run to helm and surfaces the rendered manifest without writing to the cluster.
  6. Submit. The studio opens a WebSocket subscription on k8sHelmReleaseStatus and renders the live transitions: PENDING → DEPLOYED (or FAILED).

Upgrading and Rolling Back

Releases have a History tab listing every revision with status and chart version. From any release detail page you can:

  • Upgrade to a new chart version or new values. Same wizard as install; defaults to the current values so you can edit incrementally.
  • Rollback to any prior revision. Bosca runs helm rollback <release> <revision>; the live subscription emits status transitions just like an install.
  • Uninstall, with an optional keep-history flag.

Inspecting Values and Manifest

Every release page has Values and Manifest tabs. The Values tab renders the merged effective values (chart defaults + caller overrides) via helm get values --all. The Manifest tab renders the rendered Kubernetes resources via helm get manifest. Both default to the current revision; passing a revision argument pins to a prior revision.

Security Notes

Helm subprocesses run with stringent isolation:

  • The cluster's kubeconfig is decrypted into a private temp file (0600 perms), passed via --kubeconfig <file>, and deleted in finally.
  • Values YAML is similarly written to a temp file rather than passed via argv — process listings on the controller host don't leak override values.
  • Every helm subprocess has a 300-second timeout matching the controller's streaming-response cap.
  • Helm operations require the same admin gating as every other write — see Security Model.

Result Resolution

After every install/upgrade/rollback the controller re-reads the release Secret from the cluster (the sh.helm.release.v1.<release>.v<rev> Secret) and decodes it into the wire shape. This gives a consistent result schema across read and write paths and avoids parsing helm's JSON output (which has drifted across versions).