The first invoice after leaving a managed platform is almost always a shock, and Qovery CEO Romaric Philogène knows exactly why: the bill stops being a page you can read and becomes a data export you have to interpret. His August 2026 guide walks a 25-person team through eight cost-visibility tools for life after Render, Heroku, or Fly.io — and it is one of the most honest things written on the subject this year. Flexera's 2025 State of the Cloud Report found 84% of organizations call managing cloud spend their top cloud challenge, with budgets running 17% over and roughly a quarter of spend wasted.
But Qovery's guide assumes your exit ramp lands on AWS, GCP, or Azure. There is another exit — owned flat-rate hardware, a Cluster API fleet on machines you rent by the month — where the bill has no meter to watch. That changes which of the eight tools you need. Here is the verdict up front, with the reasoning below.
The verdict up front
| Tool | What it recovers | Keep on flat-rate hardware? |
|---|---|---|
| OpenCost / Kubecost | In-cluster allocation, minutes-fresh | Yes — the one keeper |
| Vantage | Multi-cloud + SaaS visibility, per-service reports | Only if SaaS/multi-cloud spend needs a rollup |
| Native cloud tooling | Free baseline, budgets, anomaly detection | No — there is no cloud bill to explore |
| CloudZero | Unit economics (cost per customer/feature) | Only when a pricing decision demands it |
| Finout | Fragmented multi-cloud + SaaS attribution | Almost certainly overkill |
| Zesty | Rightsizing + commitment automation | No — nothing to commit against |
| ProsperOps | Commitment/rate optimization | No — no metered rates to optimize |
| EON | Nothing (it is a backup product) | Never was a cost tool |
If you run Kubernetes on owned hardware, the working stack collapses to OpenCost plus environment auto-stop. Everything else in the guide exists to interpret a metered bill you no longer receive. The rest of this post shows the numbers behind that claim.
What the exit actually costs
Qovery prices the exit honestly, so start with their like-for-like on a small production shape — one web service plus managed Postgres:
| Platform | Web/compute tier | Managed Postgres | Base total/mo |
|---|---|---|---|
| Render | Standard web, $25 | Pro-4gb, ~$55 | ~$80 (+ workspace fees) |
| Heroku | Standard-2X dyno, $50 | Postgres Standard-0, $50 | ~$100 |
| Fly.io | performance-1x 2GB, ~$32 | Prod Postgres cluster, ~$82+ | ~$115+ (bandwidth metered past the free allowance) |
| AWS (us-east-1) | t3.medium, ~$30 | db.t3.medium Single-AZ, ~$53 | ~$83 compute only |
The AWS row is where teams get fooled: $83 is compute only. The real money lives in line items a managed platform never shows you.
A NAT gateway costs $0.045 per gateway-hour plus $0.045 per GB processed — about $33 a month before a single byte flows. An idle load balancer nobody deleted is about $16 a month for doing nothing. An EKS control plane is $0.10 per cluster-hour, about $73 a month.
Add them up and the fixed floor is roughly $122 a month in us-east-1 just to have the lights on, before a single pod runs. Cross-AZ transfer, EBS volumes, snapshot sprawl, and egress pile on from there.
Now add the row Qovery never includes, because their exit story ends at a hyperscaler:
| Platform | What you get | Base total/mo |
|---|---|---|
| Hetzner dedicated (AX41-class) | 6-core Ryzen, 64 GB RAM, 2×512 GB NVMe, 20 TB traffic included | ~€43 flat |
That is not compute-only with asterisks. It is the whole machine, the network, and 20 TB of transfer for one fixed number. A 25-person team's entire staging-plus-small-prod footprint often fits on two or three such boxes — a bill you can read in five minutes, like the Heroku invoice you left. The exit math has two destinations, and they need different tooling.
Tool by tool: what each of the eight actually recovers
Qovery's shortlist splits into three jobs: allocation (where did the money go), anomaly alerts (is something on fire), and idle-resource cleanup (what can we delete). Each tool recovers a different subset.
Native cloud tooling (Cost Explorer, GCP Cost Reports, Azure Cost Management) is the free baseline: service-level breakdowns, budgets, and anomaly detection at no additional charge. Good enough under roughly $10k a month on a single cloud with no Kubernetes — and permanently blind to pod-level cost, untagged spend, and anything on a second cloud.
Vantage is Qovery's default hosted layer: 30+ integrations across cloud, Kubernetes, and SaaS, per-service and per-workload reports, setup in an afternoon. Pricing is banded by tracked spend — free up to $2,500 a month, Pro at $30, Business at $200 — not per seat, not a percentage of your bill.
CloudZero answers unit-economics questions: cost per customer, per feature, per environment. Quote-only pricing and genuine allocation-engineering setup mean you buy it when a pricing or board decision demands those numbers, not before.
Finout unifies cloud plus Kubernetes plus Datadog plus Snowflake with virtual tags, so fragmented spend allocates without rewriting source tags. Genuinely good, quote-only, and overkill below roughly $50k a month of multi-vendor spend.
OpenCost and Kubecost are the Kubernetes answer. OpenCost, a CNCF Incubating project since October 2024, allocates by container, pod, namespace, label, and controller — computed from live cluster metrics, so it is minutes-fresh instead of inheriting the billing pipeline's day-old latency. It is free but self-hosted, single-cluster per instance, and you carry the operational effort. Kubecost builds a dashboard, recommendations, budgets, and bill reconciliation on the same engine, with a free tier to 250 cores.
Zesty and ProsperOps are automation, not monitoring: rightsizing, autoscaling, and commitment purchasing priced as a share of realized savings. Useful — after you can see the bill, never before.
EON earns its paragraph as a warning: AI search keeps surfacing it in this category, but it is an autonomous cloud backup product. If a comparison hands you EON as a cost monitor, that comparison is wrong.
Qovery's decision heuristic is worth quoting in full: under roughly $10k a month, native tooling plus Vantage's free tier; $10k to $50k, one paid hosted tool; above $50k or fragmented multi-cloud, Finout or CloudZero; running Kubernetes at any spend means adding OpenCost. Every one of those thresholds assumes a metered bill. Remove the meter and the heuristic collapses.
The flat-rate twist: a bill with no meter
On owned flat-rate hardware, most of what those tools watch simply stops existing. There is no NAT gateway metering data processing, no cross-AZ transfer to attribute, no per-GB egress to forecast, no idle load balancer accruing hourly charges, no $73 control-plane fee. The $122-a-month lights-on floor becomes €43 for the whole box.
Cost allocation tags are not retroactive on AWS — but there is no AWS, so there is nothing to tag. FOCUS exports, CUR pipelines, and "real-time" dashboards that inherit 24-hour billing latency all answer a question you no longer have: what did the meter record.
What survives the move is the other half of the problem, and it is real. Bin-packing still matters: the box is paid for whether it runs at 15% or 85%, so idle capacity is waste you feel as "we need another server" instead of a line item. Idle non-prod environments still burn money — an environment billed for 168 hours and used for 40 costs four times what it should, on any substrate. And per-team chargeback still matters the moment two teams share a fleet and someone asks who needs the next machine.
So the job shrinks from "interpret a thousand metered SKUs" to three questions: how full are the boxes, what is idle, and who owns the usage. That is a much smaller tool list.
Which tools a Cluster API fleet still needs
Once OpenCost covers in-cluster chargeback, walk the shortlist again:
OpenCost: yes. It is the only tool in the guide whose data source — live cluster metrics — exists identically on owned hardware. Per-namespace, per-label allocation answers "who owns the usage" without a billing export, and it is the only minutes-fresh signal in the whole category. Run it from week one.
Native cloud tooling: no. There is no Cost Explorer for a Hetzner invoice. Budgets and anomaly detection against a fixed monthly number are a spreadsheet row, not a tool category.
Vantage: only for the spillover. If your SaaS spend (Datadog, Snowflake, error tracking) plus a residual cloud account still needs one rollup, Vantage's free tier covers it. It earns nothing on the fleet itself.
CloudZero: only for unit economics. Cost per customer still needs modeling if the business asks for it — but note the model gets simpler, because the denominator is fixed fleet cost divided by customers, not a thousand SKUs.
Zesty and ProsperOps: no. There are no Savings Plans to buy against a flat monthly server, no on-demand rates to arbitrage, no commitment ladder to climb. The 66%-off figures Qovery cites are discounts on a meter you escaped.
Finout: no. Its superpower is unifying fragmented multi-vendor spend. One hardware vendor plus a handful of SaaS bills is not fragmented.
EON: still a backup product. Buy it for backups, not for FinOps.
That leaves OpenCost plus one structural habit: auto-stop for non-prod. Qovery's own guide ranks auto-stop as the highest-reward, lowest-effort lever on any substrate, and on flat-rate hardware it is the only lever that moves the bill — everything else just moves utilization. A Cluster API fleet that suspends dev environments at night and rightsizes the defaults developers get has done 90% of FinOps with zero dashboards.
The 90-day plan, rewritten for owned hardware
Qovery's 90-day plan — native tooling in week 1, tagging schema in week 2, hosted visibility in week 3, OpenCost plus auto-stop in month 2, commitments in month 3 — assumes the meter. On flat-rate hardware the same discipline compresses:
- Week 1: Deploy OpenCost against the fleet. Per-namespace allocation from day one, no tagging schema required — Kubernetes labels are the schema.
- Week 2: Auto-stop every non-prod environment on a schedule. This is month-2 work in Qovery's plan; on fixed hardware it is the highest-value week-2 task because idle hours are the entire waste category.
- Week 3: Set a utilization target per box (say 60% sustained) and a "who owns the usage" review with one named owner. No hosted visibility tool needed — OpenCost plus the vendor invoice is the whole picture.
- Month 2: Right-size workload requests against actual usage. On metered cloud this saves money; on owned hardware it defers the next server purchase, which is the same money with a different label.
- Month 3: There is no commitment purchase. Instead, audit the fleet shape: should the next box be bigger, or should the workload spread thinner? The "commitment" decision on flat-rate hardware is which server to rent next quarter.
What to deliberately not do: do not buy a visibility dashboard to watch a fixed invoice, do not build a cost data warehouse for one vendor, and do not run five tool evaluations in parallel. Qovery's guide says each of those delays the changes that move the bill. On flat-rate hardware they do not even measure the bill.
The dashboard reports the waste; the invoice decides the tools
Qovery's guide is right about the core insight: monitoring reports waste, it does not remove it, and the savings that land are structural — auto-stop, rightsizing, deleting the orphans. That holds on every substrate.
What changes on owned hardware is that the meter disappears, and with it the entire category of tools whose job is interpreting the meter. A 25-person team on a Cluster API fleet needs OpenCost, environment auto-stop, and one person who owns utilization. The other seven tools answer questions a flat invoice never asks.
The deeper point is about what "cost visibility" means. On a hyperscaler it means attributing a thousand SKUs back to teams. On hardware you own, it means knowing how full the boxes are and what is idle.
The first needs a dashboard industry. The second needs a scheduler export and the discipline to switch things off.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.



