TL;DR: Lago is the strongest open-source answer in usage-based billing and, after Stripe took Metronome and Adyen took Orb, one of the few that cannot be acquired away from you. Two things are usually missed when people compare it: the free self-hosted stack is not the stack behind its throughput numbers — Lago itself moved events off Postgres onto ClickHouse and Kafka — and the licence is AGPLv3, which has consequences if you embed it. The alternatives worth naming are Flexprice, OpenMeter, Amberflo, Chargebee, Orb, Metronome, and splitting the meter from the biller.
Most "Lago alternatives" pages are written by vendors who want you to leave Lago. This one starts from the opposite position: Lago is good, and for a lot of teams the correct answer is to stay. The useful question is which specific thing about it is not working for you, because each complaint has a different answer.
What Lago actually is
An open-source billing platform covering subscription, usage-based, prepaid and hybrid pricing. REST API, official SDKs for JavaScript, Python, Ruby and Go, signed webhooks. Around 9,500 GitHub stars and a fast release cadence — v1.45.1 landed in April 2026 across 183 releases.
The community edition is AGPLv3 and free to self-host. The premium and cloud tiers are not publicly priced; you book a demo and they quote against your deployment.
That combination — a genuinely complete open-source biller with a commercial tier — is rare, and it is why Lago keeps appearing on shortlists after the 2026 consolidation. It is one of the few options where no acquirer can change your roadmap without your consent.
The two things worth knowing before you commit
1. The free stack and the fast stack are different stacks
You can deploy Lago with Docker, Postgres and Redis, and on a small VPS that costs single-digit dollars a month. That is real and it works.
It is not, however, the architecture behind the throughput figures. Lago started Postgres-only, validated around 10,000 events per second, and then hit the wall that every metering system hits: the problem is not ingesting millions of events, it is running analytical queries over them at the same time without the writes locking up behind the reads. Their fix was to move streamed events to a distributed ClickHouse instance, with Kafka in front, keeping Postgres for everything else. They have written about it publicly, which is to their credit.
So when you read "a million events per second" and "self-host it for ten dollars a month" on the same product, both are true and they describe different deployments. If your volumes are AI-shaped, self-hosting Lago means operating ClickHouse and Kafka, not Docker Compose. Price that honestly, because it is the difference between a side task and a platform team.
2. AGPLv3 is a real licence with real terms
"Open source" gets used as a synonym for "no constraints", and AGPL is the licence where that is least true. The network clause means that offering modified Lago as a service to third parties triggers source obligations. Running it internally is fine. Embedding a modified Lago inside a product you sell is a conversation with your lawyers, and it is the reason the commercial licence exists.
This is not a criticism — copyleft is the mechanism that makes the escape hatch credible. But it belongs in the evaluation, and it is almost never in the comparison tables.
Work out which complaint you actually have
| The complaint | What it really is | The honest answer |
|---|---|---|
| "Self-hosting is more work than we expected" | An operations problem, not a product problem | Lago Cloud. Every alternative has the same shape at your volumes. |
| "Our pricing is credits and prepaid balances" | A data-model fit problem | Flexprice, whose model is credits-first. |
| "We only need metering, the invoicing is elsewhere" | You are buying too much product | OpenMeter, Amberflo, or a metering layer in front of your existing biller. |
| "We want someone else to run it and we have budget" | A managed-service preference | Metronome or Orb — but note who owns each of them now. |
| "The licence blocks how we want to ship it" | The one genuinely structural reason to move | Lago's commercial licence, or OpenMeter, which is Apache 2.0. |
The alternatives
Flexprice — the credits-native one
Open source under AGPL-3.0 like Lago, but with credit grants, prepaid balances, per-grant expiry windows and rollover caps designed in rather than bolted on. If your pricing is credits — and AI pricing increasingly is — this is the option whose schema already matches your product, which saves you writing a ledger on top of a counter. It also publishes its prices, which Lago does not: $500/month for the Starter tier, $1,000 for Premium. Younger, with fewer public references at scale.
OpenMeter — metering and entitlements, deliberately not billing
Part of Kong since September 2025. It meters, does entitlements and balances, and then hands off for the invoice. Against Lago that is a narrower product by design: you keep your biller and replace only the counting. Particularly sensible if you already run a gateway, since the events are already passing through it.
It is also Apache 2.0 rather than AGPL, which makes it the direct answer if the licence is your objection to Lago — permissive, with no network clause to work around. Different scope, different licence, and those two facts usually decide it between them.
Amberflo — metering with a cost-governance accent
Strong metering, positioned at cloud and AI cost management as much as at monetisation. Decide which half you are buying — "what is this costing us" and "what do we charge for this" are different products sold from the same page.
Chargebee — when usage is the minority of the bill
Mature subscription billing with metered add-ons and better invoicing, tax and dunning coverage than most. If you are seats-plus-some-usage, it is a reasonable trade. If usage is the product, its subscription DNA shows.
Orb and Metronome — managed, and owned
Both are excellent engines and both are now inside payment companies: Orb at Adyen, Metronome at Stripe. If you are on Lago specifically because you did not want your billing infrastructure inside a processor, moving to either of these undoes the decision. That may still be right — if you already process on Stripe, Metronome is the path of least resistance — but make it deliberately.
Split the stack — keep the meter separate from the biller
The alternative to picking a different all-in-one is to stop having one. Metering and invoicing fail in different ways: a wrong invoice is visible and correctable, while an event that was never counted is simply gone — the traffic has passed and cannot be replayed. Keeping the meter as its own layer means changing how you charge does not mean re-instrumenting your product.
Lago vs UsageBox, stated plainly
These are not the same category, and a comparison that pretends otherwise would waste your time.
| Lago | UsageBox | |
|---|---|---|
| Scope | Full billing platform | Metering layer only |
| Metering | Yes, at scale | Yes — idempotent ingest, documented dedupe window, late-event policy, monthly rollups |
| Rating & invoicing | Yes | No. Rollups carry quantities, not amounts |
| Credits | Yes | No |
| Open source | Whole platform, AGPLv3 | The storage engine only (usagedb) |
| Operational load | Yours if self-hosted; ClickHouse and Kafka at volume | Hosted API |
If you need invoices, Lago is a product and UsageBox is not. UsageBox is worth a look only in the narrow case where you already have a biller you are keeping, and what you actually need is a defensible count in front of it. Being straight about that costs nothing and saves you an evaluation.
If you do migrate
- Export the raw event history first, before giving notice. Events with their original timestamps and idempotency keys — not aggregates, and not invoices.
- Run both systems in parallel and reconcile per meter, per period. Matching totals is not agreement; check each key.
- Write down both systems' dedupe windows and late-event policies. They will differ, and the difference is where every discrepancy will come from.
- Do not cut over mid-period, and keep the old system readable for at least one full dispute cycle.