Managed infrastructure maintenance

Your infrastructure backlog, turned into review-ready merge requests.

GitOps Assistant finds the parts of your infrastructure that are outdated, wasteful or risky. It researches the right fix and checks it against your real environment. Then it opens one small draft merge request (MR) for each fix.

You review. You merge. We run everything else.

Get started → See what lands on your desk
An illustrative run, no sound. Watch the explainer, with sound →

What you really get is time.

Every platform team has a list of work it knows it should do. Upgrades, migrations, monitoring, cleanup. The work is important, but it is never urgent. So it waits, and the infrastructure falls behind. GitOps Assistant does the boring part of that work. Your engineers keep the part that needs their judgement.

For your engineers

Review a finished change, not a research task.

The assistant reads the changelogs, gathers the metrics, writes the change and tests it. Each MR explains what it changes and why. Most reviews take minutes.

For engineering leads

The backlog shrinks without new hires.

Maintenance work arrives ready to review, inside the workflow your team already uses. Feature work does not have to stop for it. Firefighting gets rarer as the infrastructure gets current.

For the business

Current, efficient and safe infrastructure, on record.

Fewer outdated components. Less capacity reserved and never used. Fewer gaps in monitoring. A human approves every change, and every change has an audit trail.

Here is what lands on your desk.

Monday, 08:00. An engineer opens GitLab. There is no new dashboard and no chat window. There are only merge requests and issues, each one small, each one already checked by a second reviewer.

An illustrative morning. The names are examples. The labels are the ones the assistant sets: a second, independent reviewer checks every MR and labels it. You can start with the MRs it already approved.

Your GitOps repo quietly rots.

In GitOps, a git repository describes what should run in your clusters. Over time, that repository falls behind. Small problems pile up and become outages.

Pencil sketch: a repository and a cluster with three problems circled in red: chart 3 majors behind, asks 128Mi but uses 3Gi, no ServiceMonitor

Without the assistant

  • ✕ Chart upgrades stall for months because nobody has time to read the changelog.
  • ✕ Someone copied the resource requests from an example years ago. Nobody knows if they are still right.
  • ✕ Monitoring exists for what you remembered. It is missing for what you forgot.
  • ✕ Migrations and hand-applied workloads stay in the backlog for years.
The same sketch with all three problems ticked off in green by the assistant robot

With GitOps Assistant

  • ✓ A steady flow of small draft MRs. Each one makes one fix, never a big-bang rewrite.
  • ✓ Resource values come from measured usage, not guesses.
  • ✓ Missing monitoring arrives as a ready MR.
  • ✓ The migration backlog shrinks. The assistant adopts hand-applied workloads from their live state, so nothing changes at cut-over.

One MR, up close.

A one-line diff, and everything you need to trust it. The assistant puts the evidence in the MR, so you do not have to go and find it.

Draft MR !286 · from gitops-ai/rightsize-mimir-querier-94a2 · monitoring/mimir
Right-size mimir querier based on 30-day usage
values:
  querier:
    resources:
      requests:
-       memory: 5.6Gi
+       memory: 96Mi
      limits:
-       cpu: 2800m
-       memory: 5.6Gi
+       memory: 128Mi
classification flat peak/p95 1.06 avg 64Mi · p95 76Mi · peak 80Mi 8 replicas over 30d ≈ 44Gi of memory requests freed risk medium

This comes from a real MR in production. A request this far above real use is unusual, but it makes the mechanics easy to see. Safety clamps in code raised the AI model's request to the observed peak and kept the limit above it. Across 8 replicas, the change frees about 44Gi of memory that the cluster reserved but never used. How it got there →

Six outcomes. 25+ specialist agents behind them.

You do not buy a list of features. You buy infrastructure that stays current, efficient, reliable and secure. Each outcome has small agents behind it. Each agent owns one concern. Many use no AI model at all.

↑Stay current

Chart, image and controller upgrades, with every changelog read. Deprecated APIs and Flux v1 → v2 migrations.

€Run efficiently

Resource requests sized from 30 days of real usage. Idle volumes and forgotten environments found.

!Stay reliable

Probes, disruption budgets and replicas. Backup failures caught early. Each alert checked for a permanent fix.

⎇Keep git honest

What runs but is not in git gets adopted from its live state. Drift and failing reconciles become one issue per cause.

⚿Stay secure

Committed secrets move to Vault. Vault policy and audit denials get reviewed. Security posture gets reported.

✓Less toil

Monitors and dashboards written for you. MR reviews on request. Fifty warnings grouped into one issue.

See every agent at work, story by story →

Rules when the answer is known. AI when judgement helps. Code checks the answer.

GitOps Assistant is not "an AI with access to Kubernetes". It is a fixed loop: observe, analyse, validate, propose, and a human reviews. Three layers do the work, and the AI model is only one of them.

Rulesrule-based code, no AI model

Schema checks, version comparisons, metric thresholds, ownership detection, deduplication, minimal YAML patches and chart render comparisons. When the answer is known, code gives it.

Judgementan AI model, only where it helps

Reading changelogs and deciding which breaking changes apply to you. Reasoning about an incident. Writing the fix where no rule can, and the explanation in the MR.

Guardrailscode checks the answer afterwards

Safety clamps on every number. A dry-run against your real API server. A secret scan. Read-only cluster access, draft MRs only, an independent second review and a full audit trail.

If the assistant does not know, it says so.

Every MR lists what the assistant could not check. A held proposal says why it was held.
See an upgrade, step by step →

A track record, not a demo.

We have run the assistant on our own production infrastructure and on our customers' since April 2026. These are merged changes that run in production today. A human engineer reviewed and approved each one.

500+
merge requests from the assistant merged since April 2026, each a small single-purpose diff
150+
chart, image and controller upgrades since April 2026, including 25+ major-version jumps (kube-prometheus-stack 61 → 70, Velero 4 → 5, Traefik, Alloy 0.x → 1.x…)
24+
Tiller-era Helm releases, databases included, adopted into Flux v2 from live state since April 2026, in staging and production
110+
files moved off deprecated Flux APIs since April 2026, plus Flux v1 HelmReleases migrated to v2
85+
monitoring MRs since April 2026: missing ServiceMonitors / PodMonitors, and Grafana dashboards generated or repaired
240+
reliability and security fixes since April 2026: probes, disruption budgets, remediation policy, priority classes, hardened service accounts, Secrets → ExternalSecrets

Our engineers delivered larger migrations by working with the assistant, for example an ingress-nginx → Traefik / Gateway API cut-over. The assistant prepares, verifies and follows up. A human drives.

And how well it went.

Counting is easy. These numbers show quality. We measured them from 22 August to 5 October 2026, over every MR the assistant opened in that period. Each number shows what it counts.

98.7%
of merged MRs needed no change by a human before the merge (156 of 158)
80%
of the MRs that a human decided on were merged (158 of 197). The rest were closed.
53%
of prepared changes did not become an MR. Automated checks held them for a human (1,089 held, 958 opened).
85%
of the MRs that an independent AI review approved were merged after a human checked them on the live cluster (147 of 172)

The review numbers run to 29 September 2026. We do not measure incidents caused by MRs yet. Before each test cycle we close our own open MRs and generate them again. We do not count those closures as rejections.

Why not just…

You have three other options. Each one solves part of the problem.

…do nothing?

The backlog keeps growing. Every month behind makes the next upgrade bigger and riskier. The cost arrives later, as an outage or a rushed migration.

…use linters, Renovate or scanners?

They find broken rules and new versions. They do not see what runs in your cluster or how much it uses. They do not read the changelog for you or check that the change applies.

…use a general AI agent?

It is like using a bazooka. It is powerful, but you need a lot of experience and protection to guide it without collateral damage, and it usually needs broad access to act. You stay responsible for everything it does. And you are potentially handing the complete details of your infrastructure to a third party, without any filtering or guardrails.

GitOps Assistant

Looks at your real infrastructure. Prepares the actual fix. Checks it with code and against your cluster. Puts it in the review workflow you already trust.

“Doing everything by hand equates to using a shovel. A general AI agent with access to your infrastructure is like using a bazooka. It is powerful, but you need a lot of experience and protection to be able to guide it properly without causing collateral damage. You stay responsible for everything it does, but you are potentially handing the complete details of your infrastructure to a third party, without any filtering or guardrails. I wanted something in between: a scalpel. One precise cut for each job, where you control what information gets exposed. And you get all the context to decide what ships, and to accept the responsibility.”

It can propose. You decide what ships.

The assistant may be wrong. It is not allowed to be dangerous. Safety and data privacy are design constraints, not features added later.

MRDraft merge requests only

The assistant has no merge rights. Your normal review and approval flow decides what ships. Nothing reaches a cluster without a human.

RORead-only cluster access

The assistant reads live state and metrics. It cannot change your clusters. Its dry-run identity can only test a change, never apply it.

AIYour AI boundary

You choose where the AI model runs: a cloud model, an approved provider or a self-hosted model. Secrets are scrubbed first. There is no silent fallback to the cloud.

PSRespects your data, full audit trail

We do not blindly send your data or infrastructure details to third parties. The assistant can pseudonymise your data before an AI model processes it. Every run records which agents ran, which AI model they used and why each proposal was sent or held. Independent reviewers check each MR against the cluster, without exposing all your details.

Read the full security architecture →

Built first for serious Flux estates.

Support is deepest for Kubernetes with Flux CD, GitLab and Prometheus or Mimir. If you run hundreds of workloads that way, the assistant does the maintenance work your platform team never gets to. Vault, GKE and Cloudflare are also in daily use. See everything it covers, and what comes next →

A good fit if…

  • ✓ Your infrastructure is larger than your team can keep current.
  • ✓ You manage it through git, or you want to get there.
  • ✓ Upgrades, migrations and cleanup wait for months in your backlog.
  • ✓ You want a human to approve every change.

Probably not a fit if…

  • ✕ You run one or two small clusters with little maintenance debt.
  • ✕ You want an agent that changes production without review.
  • ✕ You are looking for a Kubernetes chatbot.

See what it finds in your infrastructure.

Start with a read-only assessment of one repository and its cluster. Nothing changes, and the assistant opens no MR and no issue. It uses no AI model. Then a dry run shows the proposals it would make. Nothing to install. Just MRs to review.

Get started →

What the assessment covers →

Frequently asked.

 

Can it change production on its own?

No. Every proposal is a draft MR, and the assistant has no merge rights. Its cluster access is read-only. Your normal approval flow decides what ships.

Do I have to run or host anything?

No. We operate the assistant for you. You give scoped access. That is a bot account on your forge that can open draft MRs and issues, read-only cluster credentials, and read access to your metrics. You receive merge requests.

Which AI model does it use, and where does my data go?

You choose. For each infrastructure, we agree where the AI model may run: a cloud model, an approved provider, or a self-hosted model. The assistant scrubs secrets before any AI model sees content, and it can mask identifiers. Many agents use no AI model at all. The full data policy →

Will it flood our repositories with MRs?

No. The assistant does not propose the same fix again unless something changed. There is a hard cap per repository per run. You choose which agents run, and the schedule.

How is it different from a linter or Renovate?

Linters tell you that a rule is broken. Renovate tells you that a new version exists. The assistant proposes the actual diff, sized to your real workload and checked against your cluster. The MR includes the reasoning, the evidence and what it could not check.

Does it support Argo CD, OpenShift, Ansible or our cloud?

Some of it, and more is coming. Customer demand sets the order. See what is live, in development and on the roadmap →