Architecture
This document describes the high-level architecture of the Moonin platform. It focuses on the components that are currently visible in the product and in the public deployment flow.
Platform overview
Section titled “Platform overview”Moonin is built as a multi-tenant SaaS platform deployed on Kubernetes. Customers install the moonin-agent chart in their clusters. That chart currently bundles the Discovery Agent and the Scaling Rules Agent, both authenticated with the same cluster credentials secret.
Key components
Section titled “Key components”Discovery Agent
Section titled “Discovery Agent”- watches Deployments, Jobs, CronJobs, HPAs, Namespaces, Services and related resources
- sends deployment metadata, node snapshots, CronJob inventory and cluster metadata
- uses leader election for high availability
- operates with configurable namespace and resource exclusions
Scaling Rules Agent
Section titled “Scaling Rules Agent”- applies temporary HPA changes from scaling templates
- stores rollback state
- restores previous HPA values when templates expire or are disabled
Control Plane API
Section titled “Control Plane API”The central API for deployment tracking, cluster management, organization administration, policy management, CronJob inventory and billing.
Web Application
Section titled “Web Application”The main engineering workspace provides:
- overview dashboard
- clusters, nodes and namespace inventory
- deployments, revisions and image tracking
- CronJob schedules and execution history
- errors, notifications and policies
Admin Application
Section titled “Admin Application”The Admin Console manages:
- organizations and users
- projects and cluster onboarding
- notification channel creation and maintenance
- billing settings
Notification Engine
Section titled “Notification Engine”A background worker that evaluates alert policies and event notification policies, then dispatches notifications to configured channels with schedules, throttling and silencing.
Data flows
Section titled “Data flows”Deployment tracking
Section titled “Deployment tracking”Cluster inventory and CronJob flow
Section titled “Cluster inventory and CronJob flow”Scaling execution and rollback
Section titled “Scaling execution and rollback”Authentication model
Section titled “Authentication model”- users authenticate via Google OAuth or email/password
- agents authenticate with a cluster-specific token
- the web applications proxy backend calls server-side
- the MCP server exposes read-only scoped access tokens
Storage model
Section titled “Storage model”- metadata such as organizations, projects, clusters, revisions, node snapshots and CronJobs is stored in a relational database
- failed CronJob log excerpts are stored with the execution records
- aggregated metrics and summaries are stored for fast dashboard queries
Security highlights
Section titled “Security highlights”- all agent communication uses HTTPS
- cluster tokens use constant-time comparison
- browsers never receive internal API tokens
- sanitized manifests preserve resource identities such as Secret names while redacting sensitive values