Where Moonin is going

Moonin has been in open beta since August 2026, with customers onboarding. This page states the directions the product is moving in and, above all, what we decided not to do.

No dates, deliberately. A roadmap with dates that slip is worth less than one with directions that hold.

Where the product stands today

Moonin answers three questions about a Kubernetes cluster: what changed, what is affected and what to do next. It installs as one Helm chart per cluster, with no code instrumentation and no per-service agent.

It runs on Amazon EKS, Google GKE, Azure AKS, self-managed clusters and on-premise, because it works against the Kubernetes API. It derives DORA metrics from the cluster own deployment history, exposes 16 read-only MCP tools for AI assistants, sends alerts to Slack, Microsoft Teams and VictorOps, and access is governed with enterprise SSO.

First direction: the answer should arrive where the team already works

Today the portal is where you look. That is fine for a review, but not for two in the morning: whoever is on call should not have to open a tab to learn what changed.

Alerts into Slack and Teams and the MCP tools are the path, which is why those two surfaces will gain depth before the portal does. The measure of success is that the answer arrives without anyone going to fetch it.

Second direction: more depth on the change axis

Moonin differentiator is the change axis: not how much CPU a pod uses, but what was deployed and what broke afterwards. That is where depth compounds.

Today the relationship with GitOps is deliberately minimal: Moonin reads the argocd.argoproj.io/instance label to attribute resources to their application, and nothing more. Correlating more of that flow, without operating the tool or touching manifests, is the natural direction.

Third direction: what a large buyer requires

We do not hold SOC 2 or ISO 27001, and we say so on the security page rather than hoping nobody asks. Certifying takes time and money that today go into the product.

That priority changes when a procurement process requires it: this is a decision about sequence, not a stance. We state it in this order on purpose, so nobody spends time on an evaluation their own process will reject.

What we are not going to do

There will be no automatic remediation. Moonin will not restart pods, roll back deployments or run commands on your nodes. That is a product decision, not a missing feature: diagnosing and acting are different responsibilities, and the second one is yours. The only possible mutation will remain the Scaling Rules Agent adjusting HPA and replicas, optional and disabled out of the box.

There will be no support for virtual machines, serverless functions or standalone databases. One kind of system, done properly, instead of five done halfway.

There will be no APM with code-level visibility. If what you need is to see inside a function, Moonin is not the answer, and our comparisons say so by name rather than dodging it.

About usPricingSecurity and permissionsPartner programmeRoadmapvs Datadogvs Prometheus & Grafanavs New Relicvs Dynatracevs ELK and ElasticsearchCrashLoopBackOffOOMKilledImagePullBackOffPod stuck in PendingDocumentationDemoSign upContact usArguz, the company