TL;DR: OpenMeter is Kong's, and unlike the other 2026 acquisitions this one barely changes the calculus — it is Apache 2.0, so nothing can be taken back from a version you already have. What changes is the product's centre of gravity: OpenMeter is becoming Konnect Metering & Billing, which is excellent if you run Kong Gateway and less compelling if you do not. The alternatives worth naming are Lago, Flexprice, Amberflo, Metronome, Orb, and pairing a standalone meter with the biller you already own.
Kong announced its acquisition of OpenMeter on 3 September 2025, with integration into Kong Konnect targeted for early 2026 and customer migration through the middle of the year. It has since shipped as Konnect Metering & Billing.
Set against the rest of 2026 — Stripe taking Metronome, Adyen taking Orb for $335 million, Salesforce taking m3ter — this is the least alarming of the four, for one specific reason.
Apache 2.0 changes the risk calculation
OpenMeter has always been Apache 2.0, and Kong's core products are too. A permissive licence with no network clause means the version you have is yours, permanently, to run and modify and ship inside a product you sell. An acquirer can change the roadmap. It cannot reach backwards.
That is a materially different position from an AGPL project, where the licence protects your access to the source but constrains how you can offer a modified version as a service. Both are real open source; they defend different things. If your concern is "can this be taken away", Apache 2.0 is the strongest answer in this market.
So the honest framing is not "OpenMeter got acquired, find an alternative". It is: the product's direction now points at Kong Gateway, and you should decide whether that direction is yours.
The real question: do you run Kong?
| Your situation | What to do |
|---|---|
| You run Kong Gateway or Konnect | Stay, and lean in. Metering at the gateway is where the events already are — you get usage limits and entitlement-based feature access without instrumenting application code. This acquisition made your setup better. |
| You self-host OpenMeter, no Kong | No urgency. Apache 2.0 means you are safe. Watch whether upstream features start assuming Konnect, and re-evaluate if they do. |
| You were evaluating OpenMeter Cloud, no Kong | This is where to look around. You would be buying into a gateway platform to get a meter. |
| You needed invoicing anyway | You were always going to pair it with something. Consider whether one platform is simpler. |
What OpenMeter is, and deliberately is not
It meters usage and handles entitlements and balances. It does not invoice. That is a design decision, not a gap: it is the metering half of the stack and expects to hand off.
People coming from a full billing platform sometimes read that as incomplete. It is worth stating the case for it, because splitting the stack is a defensible architecture and not merely a smaller product. Metering and invoicing fail in different ways. A wrong invoice is visible and correctable — you issue a credit note. An event that was never counted is gone: the traffic has passed, the customer's request completed, and there is nothing to replay. Keeping the meter as its own component with its own guarantees means you can change how you charge without re-instrumenting your product.
The cost is equally honest: two systems, two integrations, and a reconciliation job you now own.
The alternatives
Lago — if you want metering and invoicing in one place
Open source under AGPLv3, covering subscription, usage, prepaid and hybrid pricing, processor-agnostic across Stripe, Adyen, GoCardless and others. The natural move if the reason you are looking is that OpenMeter stops before the invoice.
Two things to price in: the licence is copyleft with a network clause, which is a stricter position than Apache 2.0 if you embed it; and the free self-hosted stack — Docker, Postgres, Redis — is not the ClickHouse-and-Kafka configuration behind its throughput numbers. At AI volumes, self-hosting means operating that.
Flexprice — if entitlements were really credits
OpenMeter's entitlements and balances get used as a credit system fairly often, and they are not quite the same thing. If what you actually need is a prepaid wallet — recurring grants on renewal, promotional grants, top-ups, per-grant expiry, rollover caps — Flexprice has that as its data model rather than as an approximation. AGPL-3.0, self-hostable, publicly priced at $500/month Starter and $1,000/month Premium.
Amberflo — metering with a cost-governance accent
Similar scope, managed rather than open source, positioned at cloud and AI cost management as much as monetisation. Decide which half you are buying.
Metronome and Orb — the managed, and owned, options
Both are strong engines and both are now inside payment companies: Metronome at Stripe, Orb at Adyen since 1 July 2026. If you were on OpenMeter partly because you wanted your metering outside a processor, these do not preserve that. Adyen's language that multi-PSP support "continues initially" is the phrase to weigh.
Keep the meter standalone
If OpenMeter's split-stack architecture was right for you and the only problem is that its roadmap now points at a gateway you do not run, the answer is a different meter, not a different architecture. That is the shape a billing-grade metering layer takes: idempotent ingest with a documented dedupe window, a stated late-event policy, per-account key scoping, and raw events you can export.
If you migrate off it
- Export raw events with their original timestamps and idempotency keys — not aggregates.
- Map entitlements carefully. OpenMeter's balance model does not translate one-to-one onto another product's credits, and the mismatch is where customer-visible errors come from.
- Reconcile per meter, per period, running both in parallel. Matching totals is not agreement.
- Write down both dedupe windows and both late-event policies before cutover. Every discrepancy you find afterwards will trace back to that difference.