What is Finowl?
The problem
On a data platform, the decision that spends the money and the document that reports it are weeks apart. An engineer sizes a cluster on a Tuesday. The invoice arrives five weeks later, aggregated by subscription, and nobody can point at the line that changed. By then the pipeline is in production and the cost is structural.
Governance has the same gap. Tagging standards, naming conventions and approved compute policies live in a wiki page, are checked by a person if anyone remembers, and are discovered to have been ignored when somebody tries to attribute a bill.
Every FinOps tool on the market reads the invoice. Reading it faster does not help: the cheapest moment to change a cluster is before it exists, and at that moment the cost is not on any bill. It is in an IaC file, in a pull request, in front of the one person who can still change it for free.
Shift-left means moving both questions — what will this cost, and does it meet our standards — to that moment.
What Finowl does
Three things, in the order a data product meets them.
1. Estimate before the build
Before a repository exists, a product owner describes the work — volumes, pipelines, refresh rates, consumers — and Finowl produces a costed projection with a confidence band: a P50 midpoint and a P80 figure sufficient in about 80% of modelled outcomes. A sponsor commits it, and that single act freezes the estimate as the agreement and sets the budget.
This is the part most cost tools have no answer for. They can tell you what you spent. They cannot tell you what to fund, and a budget nobody derived is a number somebody remembered.
2. Policy as code
Your cost and governance standards become rules with parameters and a severity, grouped into policies and pointed at environments. Budget ceilings, caps on how much any one change may add, required tags, naming conventions, approved compute policies.
They are authored once, at account or organization level, and served to every pipeline at run time. No repository holds a copy, so a rule tightened this morning applies to this afternoon's pipeline everywhere, with nothing to redeploy.
3. Enforcement in CI/CD
In the pipeline, Finowl reads your infrastructure-as-code, prices every workload it declares for the environment being deployed, diffs it against what is already running, and evaluates the policies in force. Rules either warn or fail the build.
Every run is filed against the data product it belongs to, so a cost history and a governance record exist before the first invoice does.
Two surfaces, one set of numbers
| SURFACE | WHO USES IT | WHAT IT DOES |
|---|---|---|
| finowl CLI | Engineers, in CI and on their laptops | Reads the IaC, prices it, computes the delta against the deployed state, evaluates the policies in force, and reports every run. |
| Web app | Product owners, sponsors, FinOps, admins | Estimates a product before it is built, holds the agreed budget, authors rules and policies, and shows every run and deployment next to what you were actually billed. |
The CLI carries no policy and no budget; the web app prices no IaC. Each holds one half of the answer, and the run report is where the two meet.
It reads your infrastructure-as-code
Finowl prices what your pipeline is about to deploy, which means reading the same files your deployment tool reads. Today that is Databricks Asset Bundles. Terraform is in progress.
The format is a reader, not the product. Budgets, policies, run history and identity are all independent of it — a product that migrates from one deployment tool to another keeps everything except which file Finowl parses. See What Finowl reads.
How a change reaches the board
- An engineer changes a cluster in the IaC and opens a pull request.
- CI runs
finowl breakdown --target dev. The definition is resolved for that environment and priced. - CI runs
finowl guard --target dev. It fetches the policies in force for this product and environment, diffs the planned state against what is deployed, and exits non-zero if a blocking rule is violated. - Both commands report under the product identity in
finowl.yml, sharing one run identity, so they merge into a single entry on the deployment timeline. - The product owner opens the board and sees the projected monthly cost, what this change added, and which rules passed.
$ finowl guard --target prod
Blocked Thresholds
┏━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━┳━━━━━━━━┓
┃ Threshold ┃ Type ┃ Limit ┃ Actual ┃ Action ┃
┡━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━╇━━━━━━━━┩
│ Max cost increase ($) │ increase_absolute │ 50.0 │ 58.40 │ BLOCK │
└───────────────────────┴───────────────────┴───────┴────────┴────────┘
✗ BLOCKED — one or more block thresholds exceeded.
$ echo $?
1What Finowl does not do
- It does not deploy anything. Finowl reads your definitions and never provisions, modifies or deletes a resource. Deployment stays your deployment tool.
- It does not replace your cloud bill. The projection is a model built from your IaC and current list prices. Actual spend is read separately, from Databricks system tables and Azure Cost Management, and shown next to the projection rather than merged into it.
- It does not guess an environment. Every costing command requires
--target, and the value must name an environment your definition declares. A dev number labelled as production is worse than no number. - It does not enforce the estimate. Nothing fails a merge for costing more than the estimate said. The budget is what gets enforced, and it exists only once somebody agrees to it.