GitOps Assistant reads your infrastructure-as-code repositories, checks them against live cluster state and real metrics, and opens small draft merge requests that fix things. We run it for you: there is nothing to install or operate. You just review the MRs. Every change is verified before you see it, and nothing ships without your approval.
Every cluster operator knows this. The chart version is three majors behind. The ingester is asking for 128Mi but using 3Gi. The ServiceMonitor never got written. The ExternalSecret was supposed to be created last month. Small problems pile up into outages.
The assistant started on Flux CD and Kubernetes, and that is still where it is deepest. But the engine (observe, verify, propose a minimal diff) applies to any infrastructure that lives in git. Coverage is widening steadily, and we are explicit about what is live and what is coming.
HelmReleases, Kustomizations, raw manifests, OCI sources. Flux v1 → v2 migration, Tiller/Helm 2 release adoption, CRD apiVersion upkeep, Flux itself kept current. Managed (GKE) and self-managed clusters.
See the story →Static lint of your Vault policy and auth configuration, plus triage of audit-log denials: is that denied request a misconfigured consumer or a policy that should be widened? Findings arrive as security issues; renderable policy fixes follow as draft MRs to your Vault-as-code repository (in development).
See the story →GKE cluster posture (spot / on-demand mix, multi-zone, release channel) and Google's own recommender findings, plus Cloudflare edge security (DNSSEC, HSTS, min-TLS, WAF, dangling CNAMEs). AWS and Azure posture are on the roadmap.
See the story →GitLab is the production forge today, including a security review of the GitLab instance itself (branch protection, CI secrets, runner fleet). Through the GitLab agent for Kubernetes (KAS) the assistant reaches your clusters without a direct network path or kubeconfig. GitHub draft-PR support is built and in development; Forgejo reads work today, with draft PRs next.
See the story →Platform flavour is detected automatically. Today these estates get a read-only assessment (coverage, per-object ownership, hub-and-spoke Flux topologies), with full proposal support following. Harvester is next on the roadmap.
See the story →The repository-discovery layer is controller-agnostic by design. Argo CD Application / ApplicationSet graphs are the next GitOps controller we target, so the same agents work regardless of who reconciles.
Not everything runs in a cluster. An Ansible run-log parser is built, and Ansible repositories on GitLab already get the CI/CD and runner reviews; playbook and inventory repositories as first-class targets for run-health, upgrade and hygiene MRs are planned.
See the story →Terraform / OpenTofu and cloud-provider configuration: the same "measured state vs declared state → minimal reviewed diff" loop, applied below the cluster.
See the story →Your NetBox as context: VMs and their platforms, owners, update cadence and applications, down to racks, switch ports, VLANs and IP prefixes. Agents consult it when they investigate an alert or review a change. Inventory data is masked at the source, so no raw hostname, address or serial reaches an LLM.
See the story →For VM and bare-metal estates monitored by Zabbix rather than Prometheus: host inventory (OS, hardware, resources) as context beside NetBox, and Zabbix problems as an alert source. Same masking rules as NetBox.
See the story →Cloudflare DNS in git with a CI apply, and a deterministic agent that matches every record against your live ingresses and load balancers. Records left pointing at a retired address become a draft MR in the same wave as the retirement. Zones you manage yourself get issues only.
See the story →Half in git, half hand-applied years ago? The assistant works out per object what is actually managed, and proposes adopting the rest into GitOps from the live spec, so the first reconcile is a no-op, not an outage.
See the story →Instead of a monolithic "AI SRE", GitOps Assistant is a set of 25+ small focused agents. Each owns one concern, and many are fully deterministic, with no LLM involved at all. We enable them for your estate gradually and you only get the signal you asked for.
Walks every YAML in your Flux repo and proposes fixes for missing resource requests, security-context gaps, labels, storage-class drift, and general best-practice misses, one clean MR per issue.
See the story →Queries Prometheus for 30 days of CPU/memory usage (p95 + peak) and proposes request/limit changes with the real numbers embedded in the MR body. Sizes for bursts, not averages, and post-LLM clamps refuse anything below observed peak.
See the story →Tracks Helm chart versions, OCI images, and container tags. Reads changelogs across every hop, surfaces breaking changes, renders the chart at both versions to show what actually changes, and says plainly what it could not evaluate. Targets the latest version unless a breaking change caps it.
See the story →Recognises legacy Flux v1 HelmReleases in the cluster, generates drop-in v2 replacements with values preserved verbatim, and emits the matching HelmRepository. Once the v2 release reports Ready, a follow-up proposal removes the redundant v1 object — migrate first, delete second, so one MR never carries both risks.
See the story →Finds workloads that run in the cluster but live nowhere in git (hand-applied Deployments, Tiller-era Helm releases) and proposes manifests built from the live object, so taking ownership changes nothing on day one.
See the story →Converts committed or bootstrap Secrets to ExternalSecrets backed by your Vault, guards ExternalSecret templates against engine regressions, and flags orphaned or unserved secret references before they bite during a restart.
Flag the bot as a reviewer or drop a /review comment. Personas (default, premium, quick) run in parallel, each posting its own verdict with the backing model in the header. A synthesis comment tallies the results. Swap the backing model anytime without changing the operator UX.
On-demand posture report mapping your manifests to control IDs, a PDF your CISO can read, with a strict "never falsely compliant" contract. Plus image-signature and digest provenance checks, GitLab instance review, and edge/cloud posture findings.
See the story →Finds workloads without a ServiceMonitor or PodMonitor. Generates a correct one (matching labels + metrics port) or proposes a values-block change to turn on built-in metrics exporters.
See the story →Discovers exporters from your monitors and auto-proposes Grafana dashboard ConfigMaps. It prefers upstream grafana.com community dashboards, falls back to LLM-generated specs for niche exporters.
See the story →Polls PagerDuty for recent incidents. For each, asks "could a Kubernetes manifest change have prevented this?" and opens a draft MR with the fix (OOM bumps, resource caps, probe tweaks), falling back to an issue when no manifest change applies.
See the story →Incidents rarely respect team boundaries. The assistant joins what it knows across layers (NetBox inventory, the network, Ansible runs, Kubernetes, cloud KMS) so fifty alerts from one failed uplink become one root-cause issue, and a failing playbook is traced to the probe that was missing three layers down.
See the story →Watches Velero and CNPG backup objects. Failed backups are grouped per schedule or database cluster and arrive as one issue with the evidence and a diagnosis. Stale-backup detection and schedule or retention MRs are on the roadmap.
See the story →Reviews file naming across the whole repo weekly. Proposes renames that follow <kind>_<identifier>, grounded in the file's actual content, never inferred from neighbours.
Mention the bot (@gitops-assistant deployment grafana isn't liveness-probing) and get an on-demand proposal on any workload, any cluster.
Surfaces failing Flux Kustomizations / HelmReleases, drift, and Warning events, collapsed into one digest per root cause instead of fifty tickets, with spot-node churn and probe bursts filtered out. Issues auto-close when the finding goes quiet.
See the story →A deterministic, zero-LLM HA rule pack walks every repo daily: missing PodDisruptionBudgets, single-replica workloads, absent topology spread. Proposed as surgical draft MRs, aware of your cluster's real zone and spot-node topology.
See the story →Declare maintenance windows and alert silences in git with a mandatory end time. A CI job in your alerting repository applies them to Alertmanager and PagerDuty; the assistant lints them, audits live silences, and knows about them when it triages an alert. Planned work never pages anyone and silences never outlive their reason.
See the story →Idle PVCs, hibernated databases, resources whose owner left years ago, environments that drifted apart from their siblings. Reported as issues with the evidence — a quiet cost and risk lever.
See the story →Drop a POLICY.md in your repo ("never touch this namespace", "we pin this chart on purpose") and every agent respects it. A skip annotation does the same per object.
Collects your comments on past MRs, including /skip and /reprompt. Comments get an answer, and the feedback tunes the agents' behaviour for your estate. It learns from your team.
We have run the assistant against our own and our customers' production estates since April 2026. These are merged changes running in production today, each one reviewed and approved by a human engineer.
Larger migrations (unmanaged workloads and Tiller releases into GitOps, an ingress-nginx → Traefik / Gateway API cut-over) were delivered by our engineers working with the assistant: it prepares, verifies and follows up; a human drives. Every bot-proposed MR also carries an independent review verdict as a label, so you can start with the ones a second reviewer already checked.
We run the assistant on a schedule agreed with you. Every proposal takes the same deterministic path from analysis to draft MR.
Pull manifests from git, read-only live state from the cluster, usage from Prometheus.
Deterministic rules where the answer is known; an LLM where judgement is needed.
Schema checks, chart render diff, server-side dry-run against the live cluster, safety clamps, secret scan.
Draft MR on a dedicated branch, with an issue linked for context. Slack gets a ping.
You review with the metrics + audit trail in the MR body. Merge or reject.
values:
querier:
resources:
requests:
- memory: 5.6Gi
+ memory: 96Mi
limits:
- cpu: 2800m
- memory: 5.6Gi
+ memory: 128Mi
Every resource-touching MR ships with this block. Safety clamps raised the model's request to the observed peak, kept the limit above it, and removed the CPU limit (best practice on burstable workloads). How it got there →
AI-generated infrastructure changes are only useful if you can trust them — and if using them doesn't mean handing your configuration to a third party. Safety and data privacy are design constraints here, not features bolted on.
helm template render diff at current vs target version, and a server-side dry-run against the live API server under a dedicated identity that an admission policy restricts to dryRun only, so "will the API server accept this?" is answered before you review, not after you merge.
GitOps Assistant can run inside your own infrastructure, with your own model endpoints and credentials, under a licence. Partners who operate it for their own customers can do so under a revenue-sharing agreement. Start with a read-only assessment of one repository.
Talk to us →
No. Every proposal is a draft MR, your normal approval flow still applies, and the assistant's cluster access is read-only. You decide what ships.
Not necessarily. A hosted service is available at gitops.root.lease: it is operated for you, you provide scoped access (a bot account on your forge that can open draft MRs and issues, read-only cluster credentials, and read access to your metrics) and you receive merge requests. If your data or policies require it, you can run the assistant yourself, inside your own estate and with your own model endpoints, under a licence; partners who operate it for their customers can do so under a revenue-sharing agreement. Either way, onboarding usually starts with a read-only assessment that cannot emit anything.
Yes. Each estate has a declared egress requirement: frontier cloud models, an approved provider, or self-hosted open-weight models only. Work is routed per call type, so bulk analysis can run on a small local model while judgement calls use a stronger one. A large share of the agents are deterministic and use no LLM at all.
Only to the LLM destination agreed for your estate. Secrets are scrubbed before any model sees content. With identifier masking enabled, names, hostnames, IPs and similar identifiers are replaced by aliases before leaving and restored afterwards. That works today for a first set of call types, expanding until it covers everything sent to a cloud model. For the strictest setups, inference stays on self-hosted hardware. We'll give you the written data policy: what leaves, per class, and to whom.
Flux CD on Kubernetes, Vault, GitLab, GKE and Cloudflare are in daily production use. OpenShift, AKS and RKE2 estates and GitHub are in development (read-only assessment works today). Harvester, Argo CD, Forgejo, Ansible repositories, Terraform/OpenTofu, AWS/Azure posture, NetBox and Zabbix as inventory context, and Cloudflare DNS as code are on the roadmap. If one of those is your estate, talk to us; customer demand sets the order.
No. Proposals use SHA-based deduplication with a configurable TTL, so the same fix won't be re-proposed unless something actually changed. There's a hard cap per repo per run and a global cap per analysis unit.
Yes. A POLICY.md in your repository tells every agent what to leave alone and which conventions to follow; skip annotations do the same per object. Comments on MRs are read, answered, and fed back into how the agents behave for your estate.
Linters tell you rules are broken. The assistant proposes the diff that fixes them, sized to your real workload, with the rationale and observation window embedded in the MR body.