OptScale: open source FinOps across AWS, Azure, GCP, Alibaba Cloud and Kubernetes

What OptScale does once the billing data arrives

The README describes a pipeline rather than a feature list, and it is worth reading in that order: OptScale connects to your cloud accounts and Kubernetes clusters, ingests billing and usage data, and analyzes infrastructure consumption to surface insights that eliminate waste and optimize resource usage. Everything else in the product is downstream of that ingest step.

Four feature groups follow. Cost optimization covers unused and idle resource detection for VMs, volumes and databases, rightsizing recommendations for overprovisioned instances and workloads, power management that automatically stops non-production environments outside working hours, and commitment utilization analysis for Reserved Instances, Savings Plans and Spot Instances. FinOps and governance covers dashboards for engineering, finance and product, budgeting and alerting for anomalies and overruns, tagging and ownership visibility to attribute spend to teams and projects, and policy-driven controls.

The data and AI workload group is the most specific part of the feature list, and it is where OptScale differentiates from a generic cost dashboard. It claims Databricks cost analytics with visibility into cluster usage and idle time, and S3 and object storage optimization covering lifecycle, unused buckets and storage class recommendations. The badges in the README row list Databricks, MLflow, PyTorch, TensorFlow, Spark and Kubeflow as supported technologies, and multi-cloud support for AWS, Azure, Google Cloud and Alibaba Cloud from a single instance.

One caveat about reading this README as documentation. It is largely marketing copy with screenshots and a customer testimonial, and the feature bullet lists do not map one to one onto files in the repository. The repository tree is where you can check whether a capability is real, and it turns out to be considerably larger than the bullet list implies.

The repository tree shows thirty services, not an application

This is the single most important thing to understand before evaluating OptScale. The top level is not a package with a CLI; it is a set of services. The tree contains `auth/`, `rest_api/`, `ngui/` for the user interface, `diworker/` and `diproxy/` for data import, `bumiworker/` and `bumischeduler/` for billing and metering, `metroculus/`, `subspector/`, `trapper/`, `katara/`, `risp/`, `herald/` and `insider/` as further analysis components, plus `keeper/`, `slacker/`, `jira_bus/` and `jira_ui/` for notifications and issue integration.

Naming that many components in an open source repository is unusual, and it tells you two things. It tells you the cost analysis is a distributed pipeline rather than a query against a warehouse, so operating it means running several services and dealing with message queues. The release notes confirm the shape: one entry describes fixing several diworkers processing the same task if it was redelivered by rabbit, which is a queue reliability bug in a multi worker ingestion design.

It also tells you this is the source of a commercial product. Hystax sells OptScale, the README links to the vendor site at hystax.com and to a paid AI product at optscale.ai, and the Apache-2.0 licence plus a LICENSE.md file in the tree mean the community edition is genuinely open source rather than source available. The Python version requirement is 3.9 or newer, per the badge in the README.

Release cadence and the notes worth reading first

Three recent releases are recorded, all named with date-stamped public tags rather than semantic versions. The most recent, 2026091701-public on 2026-09-17, opens with a warning rather than a feature list: it contains a critical fix updating the MinIO image source to hystax/minio, and it says to use that release for new cluster deployments. Anyone standing up a new installation should start from that tag.

The substance of that release is mostly ingestion correctness. It adds EBS read and write operations metrics on AWS, scheduled import with a time range, report import based on etag, region settings for AWS report import and resource discovery, and makes the external_id parameter optional when creating or updating an AWS data source. Two fixes are worth calling out because they are the kind of thing that silently corrupts a cost report: several diworkers processing the same task if it was redelivered by rabbit, and discovery pods being killed by out of memory. The UI side of the same release adds metered usage to the Azure resource expense breakdown and marks AWS master cloud accounts in the account list.

The release before it, 2026080701-public, adds external ID support for assumed role connections and CSV or XLSX download of date range expenses for Pools, which tells you Pools is a first class concept for shared resource billing. The one before that, 2026062501-public, is the most technically interesting: it implements OpenTelemetry, speeds up cloudaccount.config decryption with Fernet plus HKDF, raises the effectiveness of expenses indexes, fixes a primary key issue in a ClickHouse expenses query, reduces Insider worker memory usage, and reduces cloud API rate limit failures while improving their visibility.

That last release describes, in three bullets, the entire difficulty of a multi cloud cost tool: your bill is large enough that the query layer needs indexing and a fast store, your credentials need proper key derivation, and every cloud API will rate limit you.

Where the install instructions are, and where they are not

The README does not contain a runnable install command. There is no pip install line, no docker compose file to copy, and no configuration example. What it does offer is a live demo, linked twice, described as a pre-generated demo organization you can explore to see the product's features without installing anything.

That is a deliberate choice, and it is defensible for a platform of this size: the deployment involves many services, object storage for state, a queue for ingestion work and credentials for every cloud you connect. A one-line install would be a lie. But it does mean the README is not enough to get started, and the tree tells you where to look next. There is an `optscale-deploy/` directory and an `optscale_client/`, plus a `build.sh`, a `docker_images/` directory and a `docker/` related `uv_lock.sh` at the root, which together describe the packaging story. There is also a `documentation/` directory in the tree, which is where the real setup material lives.

The other thing the README offers instead of instructions is a set of screenshots that doubles as a feature tour: Databricks connection, cost and performance recommendations, Pools of resources, shared environments, a cost geo map, VM power schedules, Reserved Instances and Savings Plans pages, and a cost breakdown by owner. Those eight images describe the product's information architecture more clearly than the prose does, and if you are deciding whether the platform matches how your finance team works, that row of images is the fastest answer available.

Where OptScale sits against the alternatives

The comparison that matters is not against another open source tool so much as against three different approaches.

The first is the cloud provider's own cost console. Every major provider gives you a spend dashboard for free, it is authoritative, and it requires no integration work. What it cannot do is combine accounts across providers into one allocation view, which is the thing OptScale's single multi cloud instance is built for. If you are single cloud, the provider console is genuinely hard to beat on accuracy and zero effort.

The second is a data warehouse and hand-written SQL. Exporting cost and usage data to BigQuery or Snowflake and building your own dashboards gives you full control and no license, and it scales to questions nobody anticipated. It also makes you responsible for schema drift when a provider adds a new line item, and for building allocation logic from scratch. OptScale's release history is essentially a catalogue of that problem being solved: rate limit handling, index effectiveness, ClickHouse query fixes, multi worker task deduplication.

The third is a commercial cost management platform, which is what OptScale's vendor sells. The open source edition is the same codebase under Apache-2.0, and the README's own framing of a paid AI tier at optscale.ai suggests the tiers differ by feature set rather than by architecture. The practical question for an evaluator is which features in that bullet list exist in this repository, and the honest answer is that the README does not say, so you would have to ask, or read the `documentation/` directory.

Signals about where this project is heading

A few details in the repository are worth reading as direction rather than documentation.

The default branch is named `integration`, not main or master. That is a small thing but it tells you how the release process works: tags like 2026091701-public are cut from an integration branch rather than from a long-lived trunk, which is consistent with a vendor running continuous delivery to customers and cutting a public snapshot. It also means if you clone the repository and assume you have the released code, you may not.

The presence of a `gemini/` directory and the OptScale AI section in the README point at the current direction: cost control extended into AI spend visibility, with the README describing coverage of AI prompts, models and agents alongside cost and security guardrails. Release 2026062501-public implementing OpenTelemetry fits the same picture, since a platform with thirty services needs real telemetry before it can be operated by someone else's team.

What the repository does not offer is what you might want from a project at this scale: no published roadmap file, no architecture document in the tree, and an open issue count of 38 for a codebase with this many services. The last push was on 2026-09-24, three days before the most recent release tag, so work is landing continuously.

Editorial conclusion

OptScale is worth evaluating when cloud spend has outgrown the bill and your clouds have multiplied at the same time, because a single instance reading AWS, Azure, GCP, Alibaba Cloud and Kubernetes is the thing that makes cross cloud allocation possible at all, and the repository shows the depth of the implementation behind the claims, with separate workers for discovery, import, insiders and recommendations, a REST API and a UI component. The Apache-2.0 release is the community edition of a commercial product, which is worth weighing on its own terms: you get working source, and you should check which features in the feature list are actually in this repository rather than in the paid tiers. Verify three things before deploying. Read the release note on the 2026091701-public tag first, because it says that release contains a critical fix moving the MinIO image source to hystax/minio and recommends it for new cluster deployments. Then confirm the branch you are deploying, since the default branch is named integration rather than main. Then check the 38 open issues against your cloud, since ingestion code paths differ per provider and that is where breakage will show up.

Frequently asked questions

Official sources

1. hystax/optscale on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases