Skip to content

Resource Builder

The consolidated home for authoring and applying Kubernetes manifests and managing Helm releases, built around a Plan → Apply → Observe workflow so nothing reaches the cluster without a dry-run diff first.

Tier: Free — some features Pro

What it does

Resource Builder is one editor-first workspace for authoring Kubernetes manifests and managing Helm releases. You author one or more YAML documents in a Monaco editor with syntax highlighting, format-on-demand, and autocomplete, hover docs and schema checks for common built-in kinds. YAML syntax errors are flagged as you type; the authoritative schema check happens at Plan, against your live cluster. Plan dry-runs every document against the live cluster and shows a per-resource diff before anything changes; Apply commits the planned changes, with per-resource create/configure/error results; Observe checks per-resource readiness — phase, ready state, recent events — after apply, so you can confirm a rollout succeeded without leaving the page. Observe covers Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs, Services, Ingresses, ConfigMaps and PersistentVolumeClaims; other kinds apply normally but show no readiness. The same workspace manages Helm releases: install, upgrade, history, rollback, uninstall, and manifest diff. The release list follows the allowed namespaces: a release installed in a namespace you have left out is not listed. You can save and reload multi-file bundles, speed up authoring with smart-assist buttons that generate a linked Service/Ingress/ConfigMap from an existing workload, and drag and drop .yaml/.yml files straight into the editor.

Two sub-modes sit behind a segmented control at the top: Build, the YAML editor plus the Plan/Apply/Observe workflow, and Helm, the release manager. Saved bundles and saved Helm configs live in the Library drawer, opened with the ☰ Library button inside Build mode.

Plan and Apply both run through the expert-exec pod, so both require Expert Mode — see Setup.

Build sub-mode

The left panel is a bundle tree — a list of files that make up the current bundle. You can add a blank Custom file (the default), start from a New <Kind> starter template (Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod, Service, Ingress, ConfigMap, Secret or PersistentVolumeClaim), or drag and drop one or more .yaml/.yml files onto the tree — a dropped file stays one entry, with its --- separators kept inside it, and Plan and Apply report a result per document within that file. The center panel is a full Monaco YAML editor with syntax highlighting and multi-file editing, one document per Kubernetes resource.

YAML SYNTAX is checked as you type: a document that cannot parse is underlined in the editor, at the line and column that broke it, without waiting for Plan. The check runs server-side against the same YAML loader Apply uses, so the editor and the server cannot disagree about what parses. The same check flags a document missing apiVersion, kind, or metadata with a name.

SCHEMA assistance — autocomplete, hover docs and inline schema checks — comes from schemas bundled with KubeManta for common built-in kinds: Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, HorizontalPodAutoscaler, Namespace, ServiceAccount, Role and RoleBinding. Other kinds, including your CRDs, and a file that mixes several kinds get no schema check in the editor. Schema validity is still decided at Plan, which dry-runs the bundle against your live cluster using the API server's own schema, including your CRDs. The editor's check is a convenience; Plan has the final word.

Once a workload is present in the bundle, smart-assist buttons — Expose with Service, Add Ingress, Mount ConfigMap — each append a new linked file pre-wired to the workload's labels, selector, and ports, so you don't have to hand-copy them. Plan gives each document one of three results: create (new resource), configure (diff against the live object), or error (validation/API failure), with the rendered diff shown per resource. Apply is only enabled once Plan has run against the current bundle contents — editing after Plan disables Apply until you re-plan, so you can never apply a diff that doesn't match what's actually in the editor.

Helm sub-mode

The Helm sub-mode covers install from a chart reference or saved config, upgrade with a values editor (Monaco, dry-run supported), revision history with rollback, a rendered manifest viewer, uninstall (helm uninstall --wait), and an AI assist panel with full release context.

An upgrade is expressed as ordered value layers rather than flags. Layer 1 is Release values — everything you have set on the release, re-applied on every upgrade. + Add override file adds layer 2, applied after it, so an override only carries what it changes and wins where the two overlap. Values you never set come from the chart and move with it.

Upgrades run with --atomic and --wait applied by default, and a values-only upgrade (no override layer) also passes --reset-then-reuse-values, which takes the new chart's defaults and re-applies your explicit values on top. These are request-body fields on the upgrade API with fixed defaults, not controls in the panel.

Library drawer

The Library drawer opens from the ☰ Library button in Build mode. Saved bundles let you save the current Build-mode bundle under a name, reload it later, or delete it. Because a bundle can contain a Secret manifest, listing and loading bundles both require admin role — the same policy as saved Helm configs. Saved Helm configs is a read-only view of previously saved Helm install/upgrade configs, with a shortcut to open them in the Helm sub-mode.

Setup

Plan and Apply both dry-run and apply through the expert-exec pod, so both require Expert Mode. Enabling it is two steps: install with --set expertMode.enabled=true to deploy the expert-exec pod, then switch Expert Mode on at Admin → System. The Helm flag alone deploys the capability without turning it on, and Plan and Apply return a permissions error until the runtime toggle is set. Expert Mode is off by default.

With Expert Mode on, Plan (dry-run) is available to the viewer role and the Free tier. Apply additionally requires admin role and a Pro license — viewers see "Apply (Admin only)" and Free-tier accounts see "Upgrade to Pro to apply" instead of a working button. Helm mutating operations — install, upgrade, rollback, uninstall, and raw command exec — require admin role, Expert Mode, and a Pro license. Bundle and Library reads and writes require admin role, because a bundle can contain a Secret manifest. Every Apply, Helm mutation, and bundle save/delete is audited with actor attribution.

Troubleshooting

If Apply stays disabled after a successful Plan, check whether you edited the bundle afterward — any change to the contents invalidates the prior plan and requires a re-plan before Apply re-enables. If Plan reports an error for a resource that looks syntactically correct, remember that Plan validates against the live cluster's own API schema including installed CRDs, so an error usually means the resource genuinely wouldn't be accepted, not that the YAML is malformed. If Plan returns a permissions error rather than a schema result, that is the Expert Mode gate, not the cluster rejecting the resource: the message names which half is missing — the expert-exec pod is not deployed (reinstall with --set expertMode.enabled=true) or it is deployed and switched off (enable it at Admin → System). If Apply or a Helm mutation returns a permissions error even for an admin with Expert Mode on, check the license entitlement: Apply needs builder_apply and a Helm mutation needs helm, both Pro. Free-tier accounts can Plan but not Apply.

Generated from KubeManta 1.5.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-11-03T12:53:14Z.