ops0 lets you view and edit any Kubernetes resource YAML directly from the browser, with a full changelog of every modification made through ops0. It also detects orphan resources — cluster objects that exist outside any IaC project — so you can keep your cluster state aligned with your infrastructure code.
Edit any resource in the browser with Monaco-powered YAML highlighting and validation.
Full audit trail of every resource change made through ops0, with before/after diffs.
Find and remediate resources that exist outside your IaC projects.
Navigate to any resource in ops0 — Deployment, Service, ConfigMap, or any other kind — and click Edit YAML. The editor opens showing the current live YAML fetched directly from the cluster.
The editor is powered by Monaco (the same engine as VS Code) with:
Make your edits in the editor, then click Apply. ops0 patches the resource via the Kubernetes API using a strategic merge patch. The resource is updated in place — no pod restarts occur unless the change affects the pod template spec.
Changes applied via the YAML editor take effect immediately in the cluster. They bypass any IaC workflows — if the resource is managed by Terraform or another tool, the change will appear as drift on the next plan. Use the YAML editor for urgent fixes, and follow up by updating the source IaC.
The YAML editor works with any resource the cluster API serves, including:
| Category | Resource Kinds |
|---|---|
| Workloads | Deployments, StatefulSets, DaemonSets, Jobs, CronJobs |
| Networking | Services, Ingresses, NetworkPolicies |
| Configuration | ConfigMaps, Secrets, ServiceAccounts |
| Scaling | HorizontalPodAutoscalers, PodDisruptionBudgets |
| Custom | All CRDs installed in the cluster |
Every edit made through the ops0 YAML editor is recorded in the changelog. This gives you an audit trail of who changed what and when, without needing to parse Kubernetes audit logs.
Open any resource in ops0 and click the Changelog tab. The changelog shows a reverse-chronological list of all ops0-originated changes to that resource.
| Field | Description |
|---|---|
| Timestamp | When the change was applied |
| User | The ops0 user who made the change |
| Diff | Side-by-side before/after YAML diff |
| Applied Via | Always "YAML Editor" for browser-originated changes |
The ops0 changelog is separate from the native Kubernetes Events system. Kubernetes Events cover all cluster activity regardless of origin. The ops0 changelog tracks only changes made through ops0 — useful for answering "did someone on my team change this through ops0?" without noise from controllers and operators.
Orphan resources are Kubernetes objects that exist in the cluster but are not managed by any ops0 IaC project. They were created manually with kubectl apply, by a script, by a CI pipeline, or by a tool ops0 does not track. Over time, orphan resources accumulate cost and introduce configuration drift between what your IaC describes and what actually runs.
Navigate to your cluster → Resources → Orphan Resources tab. ops0 compares the live cluster state against all known IaC projects and surfaces objects that have no match.
The orphan list shows:
| Column | Description |
|---|---|
| Kind | Kubernetes resource type |
| Name | Resource name |
| Namespace | Namespace the resource lives in |
| Age | How long the resource has existed |
| Estimated Cost | Monthly cost estimate for compute-bearing resources (Deployments, StatefulSets, etc.) |
For each orphan resource, you have three options:
| Action | Description |
|---|---|
| Adopt | Link the resource to an existing IaC project. ops0 generates an import block that you can add to your Terraform or other IaC configuration. |
| Ignore | Mark the resource as intentionally unmanaged. It is removed from the orphan list and will not reappear unless you reset ignored resources. |
| Delete | Remove the resource from the cluster immediately. |
Deleting an orphan resource is permanent and takes effect immediately. Confirm there are no dependencies — Services routing to the resource, other pods mounting a ConfigMap, etc. — before deleting.
terraform plan output clean and reduces surprise changes.ops0 lets you create and delete namespaces directly from the cluster view, without needing kubectl.
Navigate to Kubernetes → [cluster] → Resources → Namespaces to see all namespaces with their status (Active / Terminating) and age.
Navigate to Resources → Namespaces on your cluster.
Click + Create Namespace.
Provide a name that follows Kubernetes naming rules: lowercase alphanumeric and hyphens, no dots, max 63 characters.
Click Create. The namespace appears immediately and is ready to deploy workloads into.
Deleting a namespace removes all resources inside it — Deployments, Pods, Services, Secrets, ConfigMaps, PVCs, and everything else. This cannot be undone. Verify the namespace is empty or intentionally disposable before deleting.
The namespace enters Terminating status while Kubernetes removes all its resources. This may take several minutes for namespaces with many resources or with finalizers.
Editor shows "Permission Denied" when applying changes
The ops0 service account used to communicate with the cluster does not have write permission for this resource kind. Update the ClusterRole bound to the ops0 ops0 agent service account to include the required verbs (patch, update) for the resource group.
Changelog shows no entries for a resource I know was changed
The changelog only captures changes made through the ops0 YAML editor. Changes made directly with kubectl, by a controller, or through another tool will not appear. Check Kubernetes Events or your cluster's audit log for a complete history.
Orphan Resources tab is empty but I know there are unmanaged resources
ops0 compares live cluster state against IaC projects registered in the platform. If a project has not been imported into ops0, its resources will not be matched and may appear as orphans or may not appear at all depending on the detection heuristic. Import the relevant IaC projects first, then re-check the orphan list.