Lago or OpenMeter for usage billing: when each one fits
A product team billing API or AI usage should choose Lago when the engine must also calculate invoices and collect payment, and choose OpenMeter when the core need is metering, entitlements and access enforcement that sit alongside billing systems the team already runs. Lago is an AGPLv3 platform that meters usage, applies pricing, produces invoices and hands payment collection to a gateway such as Stripe, Adyen or GoCardless, which the Lago FAQ says businesses must supply separately. Its default stack is PostgreSQL for application data, Redis as the job queue and Gotenberg for PDFs, with ClickHouse available as an optional, disabled-by-default store for high-volume events. Advanced features sit in Enterprise plans, so confirm which of the capabilities you need are in the free edition before you commit.
OpenMeter is Apache 2.0 licensed and describes itself as monetization infrastructure that can meter usage, enforce access and bill customers, or cover only the parts a stack is missing. It ingests CloudEvents, attributes usage to customers, aggregates it in real time and offers entitlements and usage-limit balances, which makes it a fit for teams that want quota enforcement in front of an existing billing system. The trade-off is runtime and maturity: its core runs Kafka, ClickHouse and PostgreSQL, the README describes its Docker Compose setup as a local evaluation stack, and releases are still beta with possible breaking changes. Kong's 2025 acquisition kept the project open source under Apache 2.0 but planned integration into Kong Konnect, so ask Kong how the roadmap affects standalone self-hosting.
The choice turns on three questions. First, must the engine produce invoices and run payment collection, or will an existing billing or payments system own that? Second, how much beta software can the team accept, given that OpenMeter's own guidance points production users toward evaluation before rollout and that upgrades may break? Third, does the team have Kafka and ClickHouse operators who can run both in production, or would Lago's PostgreSQL-first footprint be easier to support? Write these answers down before requesting a quote, because they determine the architecture, the upgrade plan and the scope of any implementation work.
Which scenario favors which platform
This table maps common billing scenarios to the platform that fits better and the condition that makes its advantage matter. Read each row against your own team, existing stack and payment setup, since the better choice usually depends on one or two constraints rather than overall feature count.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| SaaS API vendor needing invoices and card collection | Lago | Lago calculates charges and invoices and sends payment to a gateway such as Stripe, Adyen or GoCardless, so card collection is handled through that processor. OpenMeter's billing layer can connect to external invoicing providers, so confirm how much collection and dunning you need built in. |
| Platform team adding entitlements to an existing API gateway | OpenMeter | OpenMeter's entitlements and usage-limit balances are a core part of its design, and Kong's acquisition points toward Kong Konnect integration. This matters most if your gateway is already Kong, and you should confirm the current integration status with Kong. |
| AI product billing per token or per call | OpenMeter | OpenMeter ingests usage as CloudEvents and aggregates it in real time, which suits high-frequency event streams. Confirm the event volume you expect, since high-volume ingestion depends on the Kafka and ClickHouse runtime. |
| Team with no Kafka experience | Lago | Lago's Docker Compose stack centers on PostgreSQL and Redis, with ClickHouse optional and disabled by default. OpenMeter's core runtime requires Kafka, ClickHouse and PostgreSQL, so this advantage holds only if your team does not need to run those services. |
| Team needing a production-grade Helm chart today | Lago | Lago's docs point larger deployments to Helm charts and dedicated workers. OpenMeter's official Helm chart is intended for development deployments, so confirm the production path with the maintainers before committing. |
| Team that needs a stable release contract | Lago | Lago releases are tagged versions with a documented pinning recommendation. OpenMeter releases are still beta and can include breaking changes, so this matters if you cannot absorb upgrade churn. |
| Team that wants to adopt only the missing billing parts | OpenMeter | OpenMeter can meter usage and enforce access without full billing, which suits teams keeping an existing invoicing system. Confirm that your current system accepts its invoice lifecycle hooks. |
| Team needing dunning, tax or ERP sync out of the box | Lago | Lago lists NetSuite, Xero, Salesforce and HubSpot integrations, with some premium features requiring Enterprise plans. Confirm which features your edition covers before you plan around them. |
How Lago and OpenMeter are built and deployed
Both platforms meter usage and produce billing data, but they arrive at it from different directions. Lago ships a broad Compose stack centered on PostgreSQL, while OpenMeter's runtime is built around Kafka and ClickHouse, with its deployment tooling aimed at evaluation and development. The cards below cover what runs, what is optional, and what that means for operating and pinning each one.
Lago's Compose services
The self-hosted Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. Each of these is a container you must monitor, back up where stateful, and size. The clock worker handles time-driven billing jobs, so confirm it is running after any restart, since missed scheduled work is harder to spot than a failed request.
ClickHouse optional in Lago
ClickHouse is an optional external store for high-volume events in Lago and is disabled by default, so a standard deployment does not require it. Enabling it adds another stateful system with its own backups, upgrades and capacity planning. Decide this based on expected event volume and confirm with Lago which deployment shape fits your event rate before adding the component.
OpenMeter's Kafka and ClickHouse core
OpenMeter's core runtime is its API and worker processes plus Kafka, ClickHouse and PostgreSQL. Kafka and ClickHouse are required rather than optional, so your team must operate a streaming platform and an analytical store alongside the relational database. Check whether your platform team already runs these services at the reliability and support level you need before committing.
Redis and Svix in OpenMeter
Redis is optional in OpenMeter and used for distributed deduplication, while Svix handles webhook delivery when webhooks are enabled. Turning webhooks on means you depend on an external delivery component, and running deduplication without Redis changes how duplicate events are handled across instances. Ask the OpenMeter maintainers which configuration they recommend for your event volume and whether a hosted Svix option suits your data rules.
Quickstart and Helm limits
OpenMeter's Docker Compose quickstart is a local evaluation stack, not a production topology, and its official Helm chart is intended for development deployments. Teams planning production need to design their own topology, high availability and backups. Budget that design work explicitly, because it is not provided by the default artifacts.
Pinning versions in each stack
Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, and point larger deployments to Helm charts and dedicated workers. OpenMeter releases are beta and can include breaking changes, with v1.0.0-beta.236 published on October 9, 2026. Pin exact tags in both cases, and plan a staged upgrade test for OpenMeter because breaking changes are expected during beta.
Feature and runtime comparison from supplied facts
This table sets Lago and OpenMeter against each other on license, ingestion, pricing, invoicing, integrations, runtime components, release status and ownership. Read each row as a fit question: the cells show what is documented, and the last column tells you what to confirm before you commit.
| Capability | Lago | OpenMeter | Confirm before you commit |
|---|---|---|---|
| License | AGPLv3 for the platform, with MIT-licensed agent SDKs and MCP server in separate repositories | Apache License 2.0 | Whether AGPLv3 network-use obligations fit your hosting and modification plans with counsel |
| Event ingestion | Usage metering with events stored in PostgreSQL by default, with optional ClickHouse for high-volume events | Ingests usage as CloudEvents, attributes it to customers and aggregates it in real time | Expected event volume and the ingestion path your producers can emit |
| Pricing models | Usage-based metering, pricing and invoice generation within the platform | Flat, recurring, per-unit, tiered, package and dynamic prices on versioned plans and add-ons | Which price types your product needs, including the dynamic pricing you intend to use |
| Entitlements and balances | Not described in the supplied material as a core feature | Entitlements and usage-limit balances, plus customer credit balances | Whether Lago covers your entitlement or access-control needs in the edition you plan to run |
| Invoicing and payment collection | Calculates charges and invoices, then sends payments to a separate gateway such as Stripe, Adyen or GoCardless | Invoice lifecycle that can connect to external invoicing providers, with payment handling left to your stack | Which gateway or invoicing provider your finance team uses and how it is connected |
| Integrations | NetSuite, Xero, Salesforce and HubSpot listed in the README | External invoicing providers and Svix for webhook delivery when enabled | Connectors for your ERP, CRM and accounting system, and who builds any missing ones |
| Runtime components | Front end, API, API worker, clock worker, PostgreSQL, Redis and Gotenberg for PDFs, with ClickHouse optional | API and worker processes plus Kafka, ClickHouse and PostgreSQL, with Redis optional and Svix when webhooks are enabled | Operating effort for each component, including Kafka for OpenMeter and any Helm chart you plan to use |
| Deployment guidance | Docker Compose for smaller setups, with Helm charts and dedicated workers suggested for larger deployments | Docker Compose is a local evaluation stack, and the Helm chart is intended for development deployments | A production topology and supported sizing guidance from the vendor for your volumes |
| Latest release | v1.55.0 on October 7, 2026, after v1.54.0 on October 6, 2026 | v1.0.0-beta.236 on October 9, 2026, with beta status and possible breaking changes | Upgrade policy, changelog review and whether your pinned version will stay supported |
| Ownership | Chainscore Labs company, independent of the metering product vendor described here | Acquired by Kong on September 3, 2025, which planned to bring metering, entitlements and invoicing into Kong Konnect | Your long-term roadmap, Kong Konnect dependencies and whether the open-source project will remain at parity |
What the license and editions cover for each
The open-source Lago platform is licensed under AGPLv3 and is the edition you self-host. Lago's FAQ describes it as a forever-free edition with fundamental billing features, so it covers metering, pricing, invoicing and payment collection for most usage-based products.
- License: The platform is AGPLv3. If you modify Lago and make it available to users over a network, the AGPL obligations to share your modified source apply, so confirm the position with your legal team.
- Agent SDKs and MCP server: These are MIT licensed and live in separate repositories, so they can be reviewed under different terms from the core platform.
- Payment processing: Lago calculates charges and sends them to a gateway. Stripe, Adyen and GoCardless are the providers named in the README, and you hold the processor account.
- Listed integrations: The README lists NetSuite, Xero, Salesforce and HubSpot. Confirm which of these work in the free edition and which depend on an Enterprise plan.
- Pinned releases: Lago's self-hosting docs recommend pinning the last tagged version instead of the latest image tag.
Before you rely on the free edition, ask Lago which listed integrations and features it includes and read the Lago FAQ for current wording.
Lago's FAQ states that Enterprise plans add premium features on top of the open-source edition. The supplied material does not list which features those are, so treat any feature list you find elsewhere as something to verify against the contract.
- Scope of paid features: Enterprise plans add premium features to the free edition. Ask for the complete list in writing before you compare costs.
- Deployment model: Confirm whether the premium offering runs self-hosted in your own infrastructure, in Lago Cloud, or in both, since that changes who operates the platform.
- Support terms: Ask what support, response expectations and upgrade assistance the plan includes, and whether they are stated in the agreement.
- Licensing of premium code: Ask how premium features are licensed, since the open-source core is AGPLv3 and the premium code may fall under different terms.
- Contract structure: Ask whether pricing is per deployment, per usage or per seat, and which parts recur each year and which are one-time.
Request a written quote and a feature matrix that maps each premium feature to a plan and a deployment model before you decide whether the free edition covers your needs.
OpenMeter is licensed under the Apache License 2.0, a permissive license that allows commercial use, modification and redistribution with attribution and notice requirements. Its README describes the project as open-source monetization infrastructure that can meter usage, enforce access and bill customers, or fill only the gaps in your stack.
- Release status: OpenMeter releases are still beta and can include breaking changes. The latest release named in the supplied material is v1.0.0-beta.236, published on October 9, 2026.
- Runtime components: The core runs API and worker processes with Kafka, ClickHouse and PostgreSQL. Redis is optional for distributed deduplication, and Svix is used when webhook delivery is enabled.
- Evaluation deployments: The Docker Compose quickstart is a local evaluation stack, not a production topology. The official Helm chart is intended for development deployments.
- Modular adoption: You can use OpenMeter for metering and entitlements alone, or combine it with your own invoicing system.
- Licensing clarity: The Apache 2.0 license covers the open-source project. Confirm with OpenMeter or Kong which features, if any, are offered only in a commercial product.
Plan for a beta-stage upgrade path, pin versions in your deployment and review the OpenMeter repository release notes before each upgrade.
Kong announced on September 3, 2025 that it had acquired OpenMeter. Kong said the project would remain open source under Apache 2.0 and planned to bring OpenMeter's metering, entitlements and invoicing into Kong Konnect, its managed platform. The announcement describes a plan, so the timing and final scope are not settled in the supplied material.
- Stated commitment: Kong said the project remains open source under Apache 2.0. That is the license you can verify today in the repository.
- Planned scope: Kong named metering, entitlements and invoicing as areas it intends to bring into Konnect.
- Unknowns to confirm: Timing, the Konnect tier that would include these features, and whether any feature will exist only in Konnect are not stated in the supplied material.
- Gateway context: If you already run Kong for API traffic, the planned integration may matter to your architecture. If you do not, it does not change the open-source option.
- Ownership change: Ask how Kong plans to maintain the open-source roadmap and whether contributions and governance will change after the acquisition.
Ask Kong for its written roadmap and licensing commitments before you build a dependency on any Konnect-only capability, and read the Kong announcement for the original wording.
What running each platform in production takes
Lago's production footprint is the smaller and more familiar one. The Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. ClickHouse is optional and disabled by default, so most teams start with services they already know how to back up, patch and monitor. Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, and point larger deployments to Helm charts and dedicated workers. Confirm which tag your team will pin, who approves each upgrade, and how you will test a new release against a copy of your billing data before it reaches invoicing.
OpenMeter carries more moving parts and a beta risk you must plan for. Its core runtime is the API and worker processes plus Kafka, ClickHouse and PostgreSQL, with Redis optional for distributed deduplication and Svix used when webhook delivery is enabled. Each of those components needs capacity planning, backups, upgrades and alerting, and the Kafka and ClickHouse layers add specialized skills and on-call load that a billing team may not have in-house. OpenMeter's README describes its Docker Compose quickstart as a local evaluation stack rather than a production topology, and its Helm chart as intended for development deployments. Its releases are still beta and can include breaking changes, with v1.0.0-beta.236 published on October 9, 2026. Pin exact versions, read each release note before upgrading, and rehearse upgrades in a non-production environment.
Kong ownership is a roadmap question to put to Kong directly. Kong announced on September 3, 2025 that it had acquired OpenMeter, said the project would remain open source under Apache 2.0, and planned to bring its metering, entitlements and invoicing into Kong Konnect. The announcement does not settle which features will stay in the open-source project, how the release cadence will change, or whether the beta label will be lifted. Ask Kong for written answers on the open-source roadmap, the timing for a stable release, and the support options for self-hosted users before you commit. Your answers will shape how much of the operating effort on this page you should expect to carry yourself.
What drives the running cost of each
Running cost for Lago and OpenMeter comes from the same few places: the infrastructure you operate, the people who run it, the third parties you pay, and the licensing or vendor path you choose. Use the cards below to separate one-time setup from recurring spend before you ask anyone for a number.
Infrastructure footprint to operate
Lago's default Docker Compose stack runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, with ClickHouse optional and disabled by default. OpenMeter's core runtime adds Kafka and ClickHouse alongside its API, worker and PostgreSQL, and Redis is optional. Compare the number of stateful services each one needs you to back up, patch and monitor, and ask who pays for the compute, storage and network in your cloud account.
Skills needed to run each
Running Lago mainly asks for PostgreSQL, Redis and container operations, with ClickHouse added only if you enable it for high event volumes. Running OpenMeter asks for Kafka and ClickHouse operations in addition to PostgreSQL. Staffing cost follows from which of these skills you already have in-house. Ask any partner to state the roles, hours and on-call coverage it assumes for each.
Payment gateway and invoicing fees
Lago calculates charges and invoices but needs a separate payment processor such as Stripe, Adyen or GoCardless, and those providers charge their own transaction fees. OpenMeter's invoice lifecycle can connect to external invoicing providers, which also carry their own fees. These are paid to third parties and recur with volume, so model them in the same spreadsheet as your hosting. Confirm each provider's fee schedule directly.
Premium or Enterprise licensing
Lago's open-source edition is described as forever free with fundamental billing features, while Enterprise plans add premium features. If your roadmap needs features that sit in paid plans, that is a recurring licence line on top of hosting. OpenMeter's billing features are part of its open-source Apache 2.0 project, so its cost question is mainly operational. Ask Lago for a written list of which features your requirements need and their plan terms.
Kong Konnect as OpenMeter's future path
Kong announced in September 2025 that it acquired OpenMeter, said the project would remain open source under Apache 2.0, and planned to bring metering, entitlements and invoicing into Kong Konnect. If you plan to stay self-hosted, confirm which features will stay in the open-source project and which will sit behind Konnect subscriptions. A future move into a managed Kong product would change your cost structure, so request that roadmap in writing.
Upgrade testing on beta releases
OpenMeter releases are still beta and can include breaking changes, so each upgrade may need staging validation, data migration checks and rollback rehearsal. Lago's self-hosting docs recommend pinning the last tagged version instead of the latest image tag, which keeps upgrades deliberate. Budget recurring engineering time for testing and pinning either way, and ask any partner how upgrade testing is scoped and priced.
External support and retainers
Most implementation work is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, and DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any provider which items are one-time setup, which recur as retainer, and what happens to the retainer when you change versions.
Moving usage data and plans from one engine to the other
This sequence moves historical usage, customer identifiers and price logic from one billing engine to the other while keeping invoices correct throughout. The end state is one engine producing invoices and webhooks, with the old stack retired only after reconciliation passes.
Export historical usage events and retain originals
Your engineering team exports raw usage events from the current system, including timestamps, customer identifiers, event codes and dimensions, into storage you control. Keep the untransformed export as the record of truth, because both engines will ingest the same events for comparison. OpenMeter ingests usage as CloudEvents and attributes it to customers, so confirm the field mapping for your event shape before importing anything. The step is complete when event counts per customer and per billing period match the source system for a sample window you agree on.
Map customers, subscriptions and external IDs
Build a crosswalk that links each customer's identifier in your application to its record in the target engine, and each active subscription to its plan. Customer IDs are usually the easiest part to carry over, since they are yours, but payment gateway references and invoicing provider IDs must be mapped separately. Lago needs a separate payment processor such as Stripe, Adyen or GoCardless, so confirm which gateway customer objects you will reuse. The output is a reviewed mapping table with no unmatched customers or subscriptions.
Rebuild plans, prices and entitlements in the target model
Recreate each plan in the target engine rather than converting it automatically, since the two models express pricing differently. OpenMeter supports flat, recurring, per-unit, tiered, package and dynamic prices, and it models entitlements and usage-limit balances as first-class objects. Lago's plans, charges and metrics must be translated by hand against that model. Have finance sign off on a worked example per plan, showing the same usage priced by the old and new definitions, before any customer is moved.
Rebuild invoice templates and document output
Recreate invoice layout, legal entity details, tax settings and any PDF output in the target engine. Invoice templates rarely transfer cleanly between systems, so treat them as a rebuild item with its own review. Confirm with your finance and tax advisers which invoice fields are legally required in each jurisdiction you bill in. The step closes when a sample invoice for each plan type has been approved and archived alongside the source invoice it replaces.
Run both engines in parallel and reconcile
Ingest live usage into both systems for a defined reconciliation period and compare the computed charges per customer, per line item and per billing cycle. Investigate every variance, including rounding, timezone boundaries and late-arriving events, since these are the usual sources of drift. Usage ingestion should be idempotent in both engines, so duplicates from the dual feed must be checked before comparing totals. The step is complete when the variance report shows no unexplained differences and the sign-off record names who approved it.
Cut over invoicing and webhook consumers
Switch invoice issuance to the target engine for a set cohort, then move the remaining customers in batches once the first cohort's invoices and payment outcomes look correct. Repoint every webhook consumer, including entitlement checks in your product, accounting exports and CRM syncs, and test each one against the new event payloads. Note that OpenMeter's webhook delivery uses Svix when enabled, and that Lago's integrations with NetSuite, Xero, Salesforce and HubSpot must be reconfigured in the new environment. The cutover is done when no consumer reads from the old engine's events.
Retire the old stack after a retention check
Once cutover is stable, keep the old engine in read-only mode long enough to answer disputes and audit queries, then decommission its workers, databases and queues. Before deletion, confirm retention obligations for invoices, usage records and personal data with your compliance owner, and archive exports in a format you can read later. Remove unused credentials, webhooks and gateway connections, and update the runbooks. The step closes with a documented decommission record that lists what was deleted, where archives sit and who holds them.
Where implementation projects usually run long
Most delays in a Lago or OpenMeter project come from decisions that were never written down, not from the software itself. The first is the payment and tax path. Lago calculates what to charge and when, then hands the charge to a separate payment gateway, and its README names Stripe, Adyen and GoCardless as supported providers. Each gateway needs its own webhook configuration, test-mode accounts and failure handling for declined or disputed payments. Tax is a separate question: confirm early which tax engine or rules the business will use, because neither platform's supplied facts settle that for you. Ask the vendor or your tax adviser to confirm the exact integration path before the build starts.
The second source of delay is translating pricing into each engine's model. In Lago, plans, charges and metrics are configured in the billing model. In OpenMeter, the same commercial rules are expressed as versioned plans, features and entitlements, with prices such as tiered, package or dynamic types. A tiered API price that is simple on a contract can take weeks to reproduce exactly when it includes committed amounts, overage rules and mid-cycle upgrades. Event design adds a further step for OpenMeter: usage arrives as CloudEvents, so the team must agree on the type, subject and dimension fields before any dashboard or invoice can be trusted. Changing these after go-live means reprocessing history. Sizing Kafka partitions and ClickHouse storage should follow a measured event rate from a test environment, not an estimate, and both platforms' own documentation should be checked for the current recommended topology before anyone sets capacity.
Three client inputs decide whether any of this finishes on schedule. First, billing rules in writing: a signed rate card, the treatment of credits, proration, refunds and grace periods, and who approves an exception. Second, a test environment that mirrors production event volume closely enough to expose reconciliation gaps, including a webhook receiver that can be replayed. Webhook delivery reliability is worth testing deliberately, because OpenMeter uses Svix when webhooks are enabled and both platforms need retry and idempotency handling on the receiving side. Third, a named owner for finance reconciliation who signs off that metered usage, invoices and payments agree each cycle. Without that person, a technically working system still produces disputes that stall the project.
Questions buyers ask before choosing or hiring help
What drives the implementation cost of Lago or OpenMeter?
The cost is driven by how much of the billing stack you need to build around the engine, not by the engine's license, which is free to use in both cases. Lago is AGPL-3.0 and OpenMeter is Apache 2.0, so software licensing is not the line item to compare. The main cost drivers are the number of pricing models you must reproduce, the payment gateway you connect (Lago names Stripe, Adyen and GoCardless as supported providers, and it requires a separate processor), the accounting or CRM systems you sync, and the infrastructure you operate. Hosting a self-run stack, paying for Lago Premium or Lago Cloud, and paying an implementation partner are separate costs. Ask any vendor or partner for a written scope that lists each of these components and who pays for each one.
Can our team run Lago or OpenMeter without outside help?
A team with strong platform engineering and a clear billing model can run either engine in-house, but the effort differs. Lago's Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, and its docs point larger deployments to Helm charts and dedicated workers. OpenMeter's core runtime is API and worker processes plus Kafka, ClickHouse and PostgreSQL, with Redis optional and Svix used when webhooks are enabled. OpenMeter's own README calls its Docker Compose quickstart a local evaluation stack and its Helm chart intended for development deployments, so a production topology is work your team must design. Confirm which of these components your platform team already operates before deciding.
How long does a pilot take, and what sets that time?
No supplied fact gives a pilot duration for either platform, so treat any number you hear as a claim to verify. The time is set by the pricing scope: how many plans, add-ons, usage metrics and tiers you need to model, and whether you require entitlements or usage limits enforced at request time. Integration scope matters too, including the payment gateway, the invoice flow and the ERP or CRM sync. For OpenMeter, the Kafka and ClickHouse runtime adds an infrastructure step that Lago's PostgreSQL-first default avoids unless you enable ClickHouse. Ask for a fixed-scope written plan with milestones, a named set of test customers and a defined pass condition for the pilot.
Does OpenMeter's beta status block production use?
Not by itself, but it changes the risk you must accept and the upgrade plan you need. OpenMeter's README states its releases are still beta and can include breaking changes, and the latest release cited is v1.0.0-beta.236, published on October 9, 2026. Production use therefore depends on whether your team can absorb breaking changes, pin versions, test each upgrade against your billing data and keep a rollback path. Kong's acquisition, announced on September 3, 2025, says the project remains open source under Apache 2.0, but it does not promise a release status change. Ask OpenMeter or Kong for the stability roadmap and the policy for breaking changes in writing.
Does Lago's free open-source edition cover invoicing?
Lago's free edition covers fundamental billing features, and Lago's FAQ says Enterprise plans add premium features. Lago describes itself as metering usage, applying pricing, and producing invoices and payment collection. Payment collection still runs through a separate processor such as Stripe, Adyen or GoCardless, so you must integrate and operate that link yourself. Features such as dunning, progressive billing, tax and CRM or accounting integrations are the areas to check against the premium edition before assuming the free tier is enough. Confirm the exact feature list with Lago for your invoice requirements, including tax jurisdictions and the accounting system you need to sync.
What does the work need from our finance and engineering teams?
Engineering owns the deployment, the usage event pipeline, the metering model and the security controls around them, and must pin tagged versions rather than the latest image tag, as Lago's self-hosting docs recommend. Finance owns the pricing rules, the tax treatment, the invoice format, the dunning policy and the reconciliation between invoices and payments. Both teams must agree on the customer and plan identifiers that link usage to billing, because errors in those keys are hard to fix after go-live. Ask the implementation partner to name the decision owners on each side and to record sign-off points in the written scope.
How do we check how each engine handles our event volume?
Start with your expected event rate, retention period and the query windows your customers and finance team will use, then test those loads on a staging stack. OpenMeter ingests usage as CloudEvents and aggregates it in real time, so its performance depends heavily on Kafka and ClickHouse sizing. Lago stores events in PostgreSQL by default, and ClickHouse is an optional external store for high-volume events, disabled by default. Run a load test that matches your peak traffic, measure worker lag and query latency, and ask both vendors which sizing guidance applies to your volume. Don't rely on the local quickstarts for this check.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Lago vs OpenMeter, that means scoping the metering, pricing and invoicing work your team actually needs before any platform is chosen or installed.
How we scope
- Map which usage events, customers, prices and invoice flows the billing engine must handle in your own environment
- Record the payment gateway, accounting and CRM integrations the written scope must cover
- Agree deliverables and timelines in writing before work starts, since most engagements are fixed-scope
How we build
- Deploy the chosen engine in your infrastructure with its database, queue and worker services documented
- Configure pricing, metering and entitlement models against test customers and representative usage data
- Test event ingestion, invoice generation and webhook delivery against the written scope before go-live
How we hand over
- Document the running topology, version pinning approach and upgrade steps for your own platform team
- Provide runbooks for backup, restore and worker scaling tied to your deployment
- Walk your engineers through configuration decisions so they can operate and extend the stack independently
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review release notes and breaking changes for your pinned version before any upgrade is scheduled
- Ask for a written quote that follows from the agreed scope, since DeployOpen does not publish a price list
