Kubernetes + Flux CD Live
The assistant covers HelmReleases, Kustomizations, raw manifests and OCI sources. It migrates Flux v1 to v2, adopts Tiller/Helm 2 releases and keeps CRD (custom resource type) apiVersions current. It also keeps Flux itself current. It works on managed (GKE) and self-managed clusters.
See the story →HashiCorp Vault Live
The assistant runs a static lint of your Vault policy and auth configuration. It also triages denied requests in the Vault audit log. Is the consumer misconfigured, or should the policy be wider? Findings arrive as security issues. Policy fixes that the assistant can render follow as draft MRs to your Vault-as-code repository (in development).
See the story →Cloud & edge posture Live
The assistant checks GKE cluster posture (spot / on-demand mix, multi-zone, release channel) and reads Google's own recommender findings. It also checks Cloudflare edge security (DNSSEC, HSTS, min-TLS, WAF, dangling CNAMEs). AWS and Azure posture are on the roadmap.
See the story →GitLab, GitHub & Forgejo Live
GitLab is the production forge (git hosting platform) today. This includes a security review of the GitLab instance itself (branch protection, CI secrets, runner fleet). The assistant reaches your clusters through the GitLab agent for Kubernetes (KAS). It needs no direct network path and no kubeconfig. GitHub and Forgejo support is in development. For both forges, reads and draft pull requests (PRs) are built and tested. The first live write is still pending.
See the story →OpenShift, AKS, RKE2 In development
The assistant detects the platform flavour automatically. These clusters get a read-only assessment (coverage, per-object ownership, hub-and-spoke Flux topologies). Full proposal support follows. Harvester is next on the roadmap.
See the story →Argo CD Roadmap
By design, the layer that finds repositories does not depend on one GitOps controller. Argo CD Application / ApplicationSet graphs are our next target. Then the same agents will work, no matter which controller applies the changes.
Ansible Roadmap
Not everything runs in a cluster. We built a parser for Ansible run logs. Ansible repositories on GitLab get the same CI/CD and runner reviews as other repositories. Playbook and inventory repositories will become first-class targets. They will then get MRs for run health, upgrades and hygiene.
See the story →Cloud IaC Roadmap
This covers Terraform / OpenTofu and cloud-provider configuration. The assistant will apply the same loop below the cluster: "measured state vs declared state → minimal reviewed diff".
See the story →NetBox inventory Roadmap
Your NetBox will become context for the agents. It will cover VMs and their platforms, owners, update cadence and applications. It will go down to racks, switch ports, VLANs and IP prefixes. Agents will read it when they investigate an alert or review a change. The assistant will mask inventory data at the source. No raw hostname, address or serial number will reach an AI model.
See the story →Zabbix Roadmap
This is for VM and bare-metal infrastructure that Zabbix monitors instead of Prometheus. Host inventory (OS, hardware, resources) will become context beside NetBox. Zabbix problems will become an alert source. The same masking rules as for NetBox will apply.
See the story →DNS as code Roadmap
Your Cloudflare DNS will live in git, and a CI job will apply it. A rule-based agent will match every record against your live ingresses and load balancers. A record that still points at a retired address will become a draft MR in the same wave as the retirement. Zones you manage yourself will get issues only.
See the story →Mixed & legacy estates Live
Half in git, half applied by hand years ago? The assistant finds out, per object, what is actually managed. It proposes to adopt the rest into GitOps from the live spec. So the first reconcile changes nothing and does not cause an outage.
See the story →Do you use something on the roadmap? Tell us. Customer demand sets the order.