Lago vs Kill Bill vs OpenMeter

Lago fits teams that want metering, pricing and invoicing in one AGPL-3.0 engine, Kill Bill fits subscription-led billing on a Java stack, and OpenMeter fits API and AI metering on a beta Kafka and ClickHouse runtime. This page shows which fits your situation.

On this page

Which open-source billing platform fits your business model

Lago and OpenMeter lead with metering, so they suit teams whose revenue follows measured consumption, such as API calls, AI tokens or seats used per period. Kill Bill leads with subscriptions, upgrades, downgrades and a plugin model, so it suits teams whose revenue is mainly plan-based and who expect to extend billing through Java plugins. If you run usage-based pricing on a product you already operate, start with Lago for a PostgreSQL-first stack with an invoicing and collection layer, and confirm its Premium features (dunning, progressive billing, tax) against your requirements.

If your product is API or AI-first and you already run Kafka and ClickHouse or plan to, OpenMeter fits the metering path well, but treat it as beta: its releases are beta and can include breaking changes, and its own README describes the Docker Compose quickstart as a local evaluation stack and the Helm chart as intended for development deployments. Confirm the production topology with Kong and your own platform team before committing. If your core need is classic subscription billing with a Java team that will write and maintain plugins, Kill Bill is the stronger fit, but plan for a Tomcat deployment and database choice.

Whichever you choose, none of the three collects money. Each needs a separate payment gateway, such as Stripe, Adyen or GoCardless for Lago, or the gateways supported through Kill Bill plugins, so budget that integration and its PCI scope as a separate workstream. Ask each vendor or project to confirm which gateway integrations your region and currency need before you shortlist.

Which platform fits which scenario

This table matches each billing engine to the business model and team profile it suits best, with the condition that makes it the wrong choice. Read each row as a decision rule: start with your pricing model and operating skills, then check the trade-off in the last column before you shortlist.

ScenarioBest fitReason and where it is the wrong choice
Usage-based API or AI product, metered per call or tokenOpenMeterBuilt around CloudEvents ingestion, real-time aggregation and entitlements. Wrong choice if you need a stable release today, since its releases are still beta and can include breaking changes (v1.0.0-beta.236, October 9, 2026).
Usage-based product with invoicing, dunning and a PostgreSQL-first stackLagoMetering, pricing, invoices and payment collection in one platform, running on PostgreSQL, Redis and Gotenberg. Wrong choice if you need a Kafka and ClickHouse event pipeline as the core design, since ClickHouse is optional and disabled by default.
Subscription-led SaaS with plugin-driven payment gateways, tax or fraud providersKill BillPlugins deployed as JARs in the same Tomcat environment connect gateways, tax and fraud providers, and it handles upgrades, downgrades and credits. Wrong choice if your team has no Java operations capability, since it runs as a WAR in Tomcat and needs JDK 11.
Team with Java operations skills and a need for a self-managed subscription coreKill BillFits teams that already run Tomcat, JDK and relational databases, and the Apache-2.0 license imposes no copyleft obligations. Wrong choice if you expect vendor support, since Kill Bill includes no support or SLA.
Team that wants metering and billing in one Node-free, self-hosted stack with a managed path laterLagoLago Cloud and Enterprise plans exist as options, and the forever-free edition covers fundamental billing. Wrong choice if you must avoid AGPLv3 obligations on modified code, which Kill Bill's Apache-2.0 license does not impose.
Platform team that wants metering to sit inside an existing API gateway or Kong stackOpenMeterKong acquired OpenMeter and plans to bring metering, entitlements and invoicing into Kong Konnect, while the project stays Apache-2.0. Wrong choice if you need a long-term, stable self-hosted release, since the roadmap and Konnect integration are still evolving.
Teams that need a back-office UI for support and finance staffKill BillKaui provides role-based access for support, product configuration and finance reporting. Wrong choice if you need a built-in invoicing and payment collection console without a separate gateway, since Lago also provides payment collection but requires an external processor such as Stripe, Adyen or GoCardless.

Licensing and editions for Lago, Kill Bill and OpenMeter

Lago's core platform is licensed under AGPLv3, while its agent SDKs and MCP server are MIT licensed in separate repositories. The free open-source edition is described as forever free and includes fundamental billing features. Enterprise plans add premium features on top of it, so the question for a buyer is which capabilities the free edition covers and which sit behind a plan.

  • Platform license: The core billing engine is AGPLv3, which carries source-availability obligations when you modify and offer it over a network.
  • SDK license: Agent SDKs and the MCP server are MIT licensed, so client-side code that calls Lago has fewer restrictions than the platform itself.
  • Free edition: The open-source edition is described as forever free, with fundamental billing features.
  • Enterprise plans: Premium features are sold through Enterprise plans, so confirm the exact feature list and terms in writing before you plan around them.
  • Release cadence: Recent tagged releases include v1.54.0 on October 6, 2026 and v1.55.0 on October 7, 2026, so pin a tagged version and plan upgrades deliberately.

Ask counsel how AGPLv3 applies to your modifications and your hosting model, and ask Lago which features the Enterprise plans include.

How the billing pipeline fits together across the three

The core question is which component owns which step. In all three platforms, usage has to become a priced line item and then a collected payment, but the division of work differs. Lago covers metering, pricing, invoice generation and PDF output, then hands the amount to a separate payment processor such as Stripe, Adyen or GoCardless, which Lago's FAQ states businesses must supply themselves. OpenMeter focuses on the front of the chain: it ingests usage as CloudEvents, attributes it to customers, aggregates it in real time and feeds entitlements and usage-limit balances, with its invoice lifecycle able to connect to external invoicing providers. Kill Bill handles subscriptions, invoices, credits and gateway connections itself, with payment gateways added through plugins. Before choosing, map each step of your own pipeline to one of these owners and mark the gaps you would fill with your own code.

The runtime shape also differs, and it drives the operating work. A Lago 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, with ClickHouse optional and disabled by default. Your team operates several moving parts, and the clock and worker processes are what produce scheduled billing runs, so confirm how they are monitored and restarted. Kill Bill runs as a single WAR file in Tomcat, with plugins deployed as JARs in the same environment, so the integration surface sits inside one application server. OpenMeter's core runtime is its API and worker processes plus Kafka, ClickHouse and PostgreSQL, with Redis optional and Svix used when webhook delivery is enabled, which places a streaming and analytics layer at the center of usage handling.

What drives the running cost of each billing platform

Licence fees are only part of the bill for these three billing engines. The running cost comes from the services you operate, the upgrades you pin and test, the payment and plugin integrations you maintain, and the support you buy or go without. Each card below names one driver and what to request in a quote.

Infrastructure services to operate

Lago's default Docker Compose stack runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg for PDF generation. Kill Bill runs as a WAR in Tomcat with a MySQL or MariaDB style database. OpenMeter's runtime adds Kafka and ClickHouse alongside PostgreSQL. Each service needs backups, monitoring, patching and capacity planning, and that work recurs every month. Ask any quote to list each component and who operates it.

Upgrade and version pinning effort

Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, so every upgrade becomes a planned change with testing. OpenMeter releases are still beta and can include breaking changes, which raises the testing load for each move. Kill Bill ships point releases on its own cadence, and the team that upgrades it owns regression testing of invoices and payments. Ask who tests upgrades and how long a rollback takes.

Payment gateway and plugin work

Lago calculates charges and passes them to a separate payment processor such as Stripe, Adyen or GoCardless, so you maintain that gateway contract and its webhooks. Kill Bill connects to gateways such as Stripe, Braintree and PayPal through plugins deployed as JARs, and each plugin must be rebuilt and retested against new Kill Bill versions. OpenMeter sends invoices to external invoicing providers. Ask which integrations are included and who maintains each one.

Support and what is included

Kill Bill is Apache-2.0 with no support or SLA included, so every production incident, security fix and upgrade question falls to your team or a paid partner. Lago offers a forever-free open-source edition and Enterprise plans that add premium features, so you pay for features and support terms through a separate agreement. OpenMeter is beta software, so plan for internal or contracted support. Ask for response times in writing before comparing totals.

Cost of changing platforms later

Moving billing data is the expensive part of switching. Plans, prices, subscriptions, invoices and customer credit balances must map between engines, and historical invoices may need to be retained for finance and tax review. Each platform also embeds its own pricing model, such as Lago's metering-led charges, Kill Bill's subscription catalog or OpenMeter's entitlements. Ask for a data export and migration estimate covering both directions before you commit.

Implementation and internal staffing

Implementation is usually a one-time cost: designing the product catalog, configuring the pricing model, and testing invoice runs against real usage. Ongoing staffing recurs because someone must own the platform, review releases and answer finance questions about invoices. Kill Bill's Kaui back-office UI reduces some internal tooling work, while Lago and OpenMeter depend more on your own dashboards and integrations. Ask the vendor to split one-time implementation effort from recurring operations in the scope.

What implementing each platform involves

Implementation effort differs more between these three platforms than their feature lists suggest. Lago is the lightest to stand up: its self-hosted Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg for PDF generation. The team needs container operations skills, a PostgreSQL backup routine and a plan for the payment gateway, which is a separate integration because Lago calculates charges but does not collect payment. Lago's self-hosting guidance recommends pinning the last tagged version instead of the latest image tag, so the reader should confirm which tag their change process will approve and how upgrades are tested. Larger deployments are pointed to Helm charts and dedicated workers, which the reader should evaluate against their cluster standards.

Kill Bill is a standalone Java server packaged as a WAR file and typically run in Tomcat, so the implementation team needs Java application server administration. The Tomcat installation guide requires JDK 11, and the core team's regression testing covers MariaDB 10 and PostgreSQL 12, with MySQL as the core team's own database. Teams using Docker can start from the killbill/killbill, killbill/kaui and killbill/mariadb images. Kaui, the back-office UI, needs its own role configuration for support, product configuration, finance reporting and testing, and those roles should be mapped to the reader's internal access model before go-live. Payment gateway and tax or fraud plugins are deployed as JARs into the same environment, so each plugin becomes a separate version to track.

OpenMeter is the hardest of the three to run in production. Its Docker Compose quickstart is a local evaluation stack, and its README describes the official Helm chart as intended for development deployments. A production topology needs its own design across Kafka, ClickHouse, PostgreSQL, the API and worker processes, with Redis optional for distributed deduplication and Svix used when webhook delivery is enabled. That requires Kafka and ClickHouse operations skills that many billing teams do not hold in-house. Because releases are still beta and can include breaking changes, the reader should confirm the upgrade path with the maintainers, test every release in staging, and decide how it will be pinned. Before committing, ask for a written production reference architecture and confirm how Kong's ownership affects the roadmap for self-hosted users.

What buyers ask before choosing open-source billing

Is the free open-source edition enough for a billing team?

The free edition is enough when your needs are the fundamental billing features: metering, pricing, invoicing and payment collection through a gateway you connect yourself. Lago's FAQ describes a forever-free open-source edition with fundamental billing features and Enterprise plans that add premium features. Before deciding, list the features you need, such as dunning, tax, or accounting and CRM sync, and check each against the current edition documentation. Ask the vendor to confirm in writing which features sit in each tier.

What does an implementation consultant or services partner actually do?

A services partner plans, implements, customizes, integrates, hardens, backs up, upgrades and documents the platform inside your own infrastructure. For billing, that usually means mapping your plans and price models to the platform, connecting your payment gateway and accounting system, setting up the deployment, and producing runbooks. DeployOpen works this way for self-hosted open-source platforms and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner for the written scope, the named deliverables and what happens after go-live.

How much effort does a self-hosted billing deployment need?

Effort depends on the services you run, the volume of usage events and how many people will operate the system. Lago's Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, while OpenMeter's core runtime adds Kafka and ClickHouse. Kill Bill runs as a Java server in Tomcat with a relational database, plus plugins for each gateway. Each added service means more upgrades, backups and monitoring. No public effort figure is supplied here, so ask vendors and partners for a sized estimate based on your event volume and integrations.

What drives the cost of running billing on our own infrastructure?

Cost has two parts: the one-time work to deploy, integrate and test, and the recurring work to operate, upgrade and support the platform. The main drivers are the number of pricing models, the gateways and accounting systems you connect, your usage event volume, and your internal staffing. Software licenses for the three platforms are free to use under their open-source terms, so budget the services, infrastructure and staff time instead. When requesting a quote, ask for the work broken into one-time and recurring items, the assumptions behind event volume, and what is excluded.

Can our engineers run a billing platform without outside help?

A team can run it alone if it already operates PostgreSQL, a job queue, container platforms and a payment integration, and has someone who owns billing logic. The first deployment is usually where outside help pays off, since pricing configuration, gateway connections and invoice formats take time to get right. Check the upgrade path too: Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, and OpenMeter's releases are still beta with possible breaking changes. Ask whether your team can meet those upgrade and testing duties on its own.

How hard is it to move billing data to another platform later?

Switching is manageable when you keep your own copy of customers, plans, subscriptions, usage history and invoices in a documented format, and it is hard when billing logic lives only inside one platform's configuration. Usage data is the first thing to plan for, because metering platforms store events and aggregates differently from subscription engines. Test the export and reconciliation path before committing, and confirm that invoice history and open balances can be carried across without breaking tax or payment records. Ask any partner to include a migration path in the written scope.

Does the open-source license create any obligations for us?

It depends on the license and how you use the software. Lago's platform is licensed under AGPLv3, which carries source-availability duties when you modify and offer it over a network, while its agent SDKs and MCP server are MIT licensed. Kill Bill uses the Apache License 2.0 with no support or SLA included, and OpenMeter is also Apache 2.0. Have your legal team review the license terms for your specific modifications and hosting model before going live.

How to shortlist and test one billing platform in your environment

This sequence turns the Lago, Kill Bill and OpenMeter comparison into a shortlist you can test on your own infrastructure, with a documented decision at each step before any production commitment.

  1. Confirm your revenue model first

    Finance and product leads list every charge type the business needs: pure usage metering, recurring subscriptions, prepaid credits, or a mix. Lago and OpenMeter are built around metering and usage-based prices, while Kill Bill is built around subscription lifecycles that also handle usage. Write each price type, billing period and proration rule as a test case. The step is done when the list is signed off and each candidate has a clear first-fit or gap against it.

  2. Map payment gateway and ERP connectors

    Engineering and finance list the payment gateways and accounting or ERP systems the invoices must reach. Lago names Stripe, Adyen and GoCardless as supported gateway providers and lists NetSuite, Xero, Salesforce and HubSpot integrations, and it requires a separate payment processor for collection. Kill Bill connects to gateways such as Stripe, Braintree and PayPal through plugins. Confirm each connector you need against the current documentation and record which ones you would have to build or maintain yourself. The step closes with a written connector matrix per candidate.

  3. Check the license against your hosting model

    Legal and procurement review how each license applies to your plans. Lago's platform is AGPLv3, its agent SDKs and MCP server are MIT, Kill Bill is Apache License 2.0 with no support or SLA included, and OpenMeter is Apache License 2.0. Ask counsel whether AGPL obligations apply to any modifications you run as a network service, and confirm whether you need a commercial support or SLA arrangement from a vendor or partner. The step is done when counsel has written a view for each candidate and the support gap is recorded.

  4. Run a proof of concept in your own infrastructure

    Platform engineering deploys each shortlisted candidate in a non-production environment that matches your cloud account, network controls and database standards. Lago's Docker Compose stack runs PostgreSQL, Redis and Gotenberg, with ClickHouse optional and disabled by default. OpenMeter's Compose quickstart is a local evaluation stack, and its runtime adds Kafka, ClickHouse and PostgreSQL. Kill Bill runs as a WAR in Tomcat with JDK 11 and MySQL as the core team's database. Replay a sample of real event volume and one month-end invoice run, then record the operating tasks each stack creates. The step closes with a runbook and a list of services your team would operate.

  5. Verify invoicing, credits and dunning behavior

    Finance validates invoice output from the proof of concept against the test cases from step one. Check proration, credit balances, tax handling and the invoice lifecycle in each candidate, and confirm which features sit behind a paid edition. Lago's free edition covers fundamental billing features, while Enterprise plans add premium features, so list any feature you need that falls outside the free scope. The step is done when every test case has a pass, fail or gap result and the premium items are priced through a written quote.

  6. Assess maturity and release cadence

    Engineering reviews release history and stability signals for each candidate. OpenMeter's releases are still beta and can include breaking changes, with v1.0.0-beta.236 published on October 9, 2026, and Kong announced its acquisition of OpenMeter on September 3, 2025. Lago's latest release in the supplied facts is v1.55.0 from October 7, 2026. Kill Bill has been in production since 2010, with 0.24.22 published on September 29, 2026. Record how often each project ships breaking changes and how you would absorb them. The step closes with a risk register entry for each candidate.

  7. Pin a version and document the upgrade path

    Platform owners select one tagged release for each candidate that passed the proof of concept and write the upgrade procedure before production. 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. Set a test environment that receives each new release first, and ask any vendor or partner what they will support during upgrades. The step is done when the pinned version, backup plan and rollback procedure are approved by the CIO or head of IT.

How DeployOpen helps choose and implement a billing platform

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 a billing shortlist, that means we help you test the metering, pricing and payment gateway model against your business before any build starts, then carry the chosen platform through to a documented, supported deployment.

How we scope

  • We map your pricing models, such as flat, tiered, usage-based and prepaid, to each candidate's supported price types.
  • We confirm which payment gateway, tax, accounting and CRM integrations your finance and sales teams need from day one.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

  • We deploy the chosen platform in your infrastructure, with its database, job queue and worker services sized to your event volume.
  • We build the gateway connection, invoice flow and data export integrations, and test them against sandbox payment accounts.
  • We run security testing on the billing APIs and admin interfaces, and document the configuration and version pinning decisions.

How we hand over

  • You receive architecture notes, runbooks for upgrades and backups, and a record of every configuration decision made during the build.
  • We walk your engineering and finance teams through invoice runs, usage ingestion checks and the operational tasks they will own.
  • We prepare the controls and evidence your compliance assessors will ask for, while independent auditors issue any formal assessment.

How we support

  • Ongoing support, version upgrades and continuous security testing are available as retainers after handover.
  • Retainers can cover tracking of release notes for the platform you chose, including beta or breaking changes where they apply.
  • Ask any provider to confirm the support windows, upgrade responsibilities and escalation path in writing before you sign.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.