Architecture Overview
KOSTRA is a Kubernetes-native platform offered two ways: as a fully managed SaaS that KOSTRA operates for you, or self-hosted in your own environment when you need it. Both run the same software; only who operates the cluster differs. This page describes how the system is structured and how data moves through it.Deployment options
- Managed SaaS. KOSTRA runs and maintains the platform for you. You connect your cloud accounts and start using it — no cluster to operate, upgrades handled for you. This is the fastest way to get value.
- Self-hosted. For customers with data-residency, compliance, or policy requirements, KOSTRA can run inside a Kubernetes cluster you control — including in your own cloud region. You operate the cluster; the platform is identical to the SaaS.
Core services
KOSTRA is composed of focused services, each with a single responsibility:- rest_api — the primary API, backed by MySQL. It serves organizations, pools, resources, expenses, recommendations, allocation rules, and chargeback.
- auth — authentication and authorization, issuing tokens used across the platform.
- ngui — the KOSTRA web interface (React), which talks to a GraphQL server that in turn calls rest_api and auth.
- diworker and diproxy — billing and resource import. These connect to each provider, pull billing and discovery data, and write it to the data stores.
- bumiworker — the recommendation engine. It runs optimization modules on a schedule and records dated, evidence-backed findings.
- metroculus — collection and storage of resource utilization metrics used for rightsizing.
- insider — cloud pricing data used to quantify savings.
- herald — notifications and email delivery for alerts, reports, and account events.
- risp — reserved-instance and savings-plan analysis.
Data stores
KOSTRA uses purpose-fit databases:- MySQL — transactional data for the API (organizations, users, resources, rules).
- MongoDB — raw billing records and recommendation output.
- ClickHouse — high-volume expense analytics for fast aggregation over time.
- Redis — caching and coordination.
- InfluxDB — time-series data used by supporting services.
How data flows
The path from a provider bill to a dashboard is straightforward:- You connect a cloud account by supplying read-oriented credentials.
- diworker imports billing and discovers resources through the provider SDKs.
- Raw records land in MongoDB; normalized expenses are written to ClickHouse for analytics.
- bumiworker evaluates recommendation modules against resources, metrics, and expenses, and writes findings back.
- rest_api exposes the results, and ngui presents dashboards, recommendations, chargeback, and modernization views.