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.
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 can follow as draft MRs.
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.
GitLab is the production forge today, including a security review of the GitLab instance itself (branch protection, CI secrets, runner fleet). GitHub draft-PR support is built and in acceptance.
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.
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. Ansible run-log ingestion exists today as a compliance evidence source; playbook and inventory repositories as first-class targets for upgrade and hygiene MRs are planned.
Terraform / OpenTofu and cloud-provider configuration: the same "measured state vs declared state → minimal reviewed diff" loop, applied below the cluster.
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.
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.
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.
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.
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.
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.
Converts committed or bootstrap Secrets to ExternalSecrets backed by your Vault, keeps ExternalSecret templates on the current engine, 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.
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.
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.
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.
Watches Velero and CNPG backup objects. Flags failed or stale backups, proposes schedule changes, retention policy fixes, or missing BackupStorageLocations.
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.
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.
Declare maintenance windows and alert silences in git; the assistant keeps Alertmanager and PagerDuty in sync, so planned work never pages anyone and silences never outlive their reason.
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.
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 👎 reactions and comments on past MRs. 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: 256Mi
Every resource-touching MR ships with this block. Safety clamps refused to cut the limit below observed peak, and removed the CPU limit (best practice on burstable workloads).
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 is a managed service. You grant scoped, read-only access to a repository and its cluster; we operate, tune and supervise the assistant; your team receives reviewed draft merge requests. Start with a read-only assessment of one repository.
Request an assessment →
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.
No. We operate the assistant 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. 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, RKE2 and Harvester estates and GitHub are in acceptance (read-only assessment works today). Argo CD, Ansible repositories, Terraform/OpenTofu and AWS/Azure posture 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.