When to choose Lago or Kill Bill for usage-based billing
A billing team that must charge for metered usage and asks which open-source engine to self-host should start with the shape of its price list, not with the software. If most revenue comes from counting events such as API calls, tokens, seats-hours or storage, and invoices are built from those counts, Lago fits the metering-led model most directly. Lago meters usage, applies pricing, produces invoices and hands the charge to a separate payment gateway such as Stripe, Adyen or GoCardless. Its self-hosted footprint is a set of services the team already knows how to run: 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. The AGPL-3.0 license of the platform is acceptable only if the company is comfortable with its obligations when it modifies and offers the software over a network, so legal review belongs in the first week.
Kill Bill fits subscription-led catalogs where recurring plans, upgrades, downgrades, invoices and credits are the core and usage is an add-on. It is a standalone Java server packaged as a WAR file, typically run in Tomcat, and the installation guide requires JDK 11, so the team needs Java and Tomcat operations skills and a plan for the database, since the core team tests against MySQL, MariaDB 10 and PostgreSQL 12. Kill Bill is licensed under Apache-2.0, which many procurement teams prefer, and gateway, tax and fraud integrations arrive as plugins deployed as JARs in the same environment. Confirm with the Kill Bill project which plugins your gateway needs and whether they are maintained for your versions. Kill Bill ships with no support or SLA, so a team that needs contractual response times must buy them elsewhere.
Five decision drivers settle most cases: the pricing model (metered versus subscription-led), the payment gateway and whether a supported plugin exists for it, the licensing posture (AGPL-3.0 versus Apache-2.0), the support requirement, and the in-house skills to run Python-era Rails-free Lago services or Java and Tomcat. Write each driver down with an owner before comparing features, because a team that cannot staff Java operations or accept an AGPL obligation has its answer before any demo. Ask both projects and any implementation partner for a written scope that names the gateways, databases and upgrade plan you intend to use.
Which billing platform fits which business model
This table maps common business models to the platform that usually fits better and the condition that decides it. Read each row against your own pricing, team skills and support requirements, since a fit depends on the conditions in the reason column.
| Business model | Better fit | Reason and the condition that matters |
|---|---|---|
| API or AI product billed per unit | Lago | Lago is built around metering usage events, applying pricing and producing invoices. This matters most when usage volume and per-unit pricing change often and you want metering to be the core of the system. Confirm that your event volume fits the default PostgreSQL store or plan for the optional ClickHouse store. |
| SaaS with tiered plans and add-ons | Either, depending on the subscription model | Kill Bill is designed around subscriptions, upgrades, downgrades, invoices and credits, so it suits complex subscription lifecycles. Lago also handles plans and usage, so choose Kill Bill if subscription state changes are the hard part and Lago if metered charges dominate. |
| Enterprise with existing Java operations | Kill Bill | Kill Bill is a Java server deployed as a WAR file, typically in Tomcat, with plugins as JARs. Teams that already run JDK-based services and Tomcat can reuse that skill set. Confirm your JDK version against the Tomcat installation guide before you commit. |
| Team that wants a PostgreSQL and Docker-first stack | Lago | Lago's Docker Compose deployment runs PostgreSQL, Redis and a set of workers, and its self-hosting guide recommends pinning tagged versions. This suits teams comfortable operating those services. Confirm the operating effort for your own environment before committing. |
| Team needing paid vendor support or an SLA | Neither as open source alone; confirm vendor terms | Kill Bill ships under Apache-2.0 with no support or SLA included. Lago's open-source edition is free, and its Enterprise plans add premium features. Ask each vendor what support, SLA and upgrade assistance is contractually available before you choose. |
| Team that wants to keep billing logic in Kill Bill but needs an outside partner for implementation | Kill Bill with a fixed-scope implementation | DeployOpen can plan, implement, integrate, harden and document a self-hosted Kill Bill deployment in your infrastructure under a written scope. Ask for the scope, deliverables and timeline in writing before work begins. |
| Team needing a lower-effort start with a payments gateway already in place | Lago | Lago calculates charges and invoices, then sends payment to a separate gateway such as Stripe, Adyen or GoCardless. Kill Bill also connects to gateways through plugins. Confirm which gateway plugins or integrations your provider supports before you choose. |
How Lago and Kill Bill are built and what that means for operations
Both platforms are self-hosted billing systems, but they are assembled very differently. Lago is a set of cooperating services with a fixed PostgreSQL, Redis and PDF component set, while Kill Bill is a single Java server in a servlet container with plugins loaded beside it. The cards below cover what each layout means for patching, scaling and on-call work.
Lago's service set
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. Each service is a separate moving part that your team must monitor, restart and upgrade together. Check that your on-call runbook covers a stalled worker as well as a failed API, because billing runs depend on both. Confirm which services your chosen deployment method runs in separate containers or pods.
Optional ClickHouse for event volume
ClickHouse is an optional external store for high-volume events and is disabled by default. Enabling it adds a second data system to back up, monitor and upgrade, which changes the on-call surface more than any single feature. Decide early whether your event volume justifies it, and ask Lago's team or your own load tests to confirm where the default PostgreSQL store stops being adequate for your workload.
Kill Bill's WAR in Tomcat
Kill Bill ships as a standalone Java server packaged as a WAR file and is typically run in Tomcat. Patching usually means replacing the WAR and restarting the container, so your team owns the servlet container, JVM and application lifecycle. Confirm the JDK version required by the Tomcat installation guide before you plan a host image, since the guide specifies JDK 11.
Plugin JARs and payment integrations
Payment gateways, tax and fraud providers connect to Kill Bill through plugins deployed as JARs in the same environment as the server. Each plugin version has to match the core release you run, so a core upgrade can force coordinated plugin upgrades and retests. In Lago, payment collection sits with a separate processor such as Stripe, Adyen or GoCardless, so the integration burden is different. Ask which plugins your gateways need and who maintains them.
Database choice for each platform
Lago depends on PostgreSQL for application data, so PostgreSQL backup, failover and tuning are central to its operations. Kill Bill's core team uses MySQL and runs regression tests against MariaDB 10 and PostgreSQL 12, and users have also deployed it with Oracle, Percona and Aurora. Your DBA standards and existing database skills will decide which path carries less risk. Confirm the supported database versions for the release you plan to run.
Pinning versions and upgrade cadence
Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, so upgrades become deliberate changes you schedule and test. Lago's own release history moves quickly, with v1.54.0 and v1.55.0 published a day apart in October 2026, so budget time to review each tagged release. Kill Bill's 0.24.x line receives updates through its release page, and both platforms need a staging environment that mirrors production billing runs.
Pricing models, gateways, stack and licensing side by side
This table sets Lago and Kill Bill against the same billing needs: metering, subscriptions, gateways, stack and license. Read each row as a checklist for your own requirements, and use the confirm column to see which details still need a vendor answer before you decide.
| Capability | Lago | Kill Bill |
|---|---|---|
| Core focus | Usage metering, pricing, invoicing and payment collection as monetization infrastructure | Subscription billing and payments platform with recurring and usage-based subscriptions |
| Subscriptions, upgrades and downgrades | Covered by the platform's billing features; confirm plan change and proration behavior for your plans | Handles upgrades and downgrades, invoices and credits as core functions |
| Payment gateways named in supplied sources | Stripe, Adyen and GoCardless; a separate payment processor is required | Stripe, Braintree and PayPal; gateways connect through plugins deployed as JARs |
| Integrations named in supplied sources | NetSuite, Xero, Salesforce and HubSpot | Tax and fraud providers through plugins; confirm which ERP and CRM connectors exist |
| Back-office UI | Confirm the admin interface and role model in the current release | Kaui, with role-based access for support, product configuration, finance reporting and testing |
| Database support | PostgreSQL for application data; Redis as job queue; ClickHouse optional for high-volume events | MySQL used by the core team; regression tested on MariaDB 10 and PostgreSQL 12; Oracle, Percona and Aurora reported by users |
| Runtime | Docker Compose with front end, API, API worker, clock worker, Gotenberg for PDFs; Helm charts for larger deployments | Standalone Java WAR typically run in Tomcat, with JDK 11 in the Tomcat installation guide |
| License | AGPLv3 for the platform; agent SDKs and MCP server are MIT in separate repositories | Apache License 2.0, with no support or SLA included in the project |
What AGPL-3.0 and Apache-2.0 mean for your organization
Counsel and procurement usually start with the license files and the commercial paper. Lago's core platform is licensed under AGPLv3, while Kill Bill is licensed under the Apache License 2.0. Both allow commercial use, but they differ in what they require when code is changed and when software is made available to users over a network. Procurement should also keep the free software and any paid agreement separate, because support and service commitments come from a contract, not from the license itself. Lago's agent SDKs and MCP server are MIT licensed in separate repositories, so they can be reviewed on their own terms.
- Copyleft scope: AGPLv3 can require source availability for modified versions that users interact with over a network. Apache-2.0 is permissive and does not carry that obligation for your own changes in the same way.
- Separate SDK licenses: The MIT terms for Lago's SDKs and MCP server apply to those repositories, so include them in your inventory.
- No support or SLA with Kill Bill: Kill Bill's license comes with no support or SLA, so any service commitment must be written into a separate agreement.
- Edition boundaries: Lago's general FAQ describes a free open-source edition with fundamental billing features and Enterprise plans with premium features. Ask for the Enterprise terms in writing.
Ask counsel to review the exact license files in the repositories and versions you plan to deploy, along with any Enterprise order form.
Engineering teams feel license terms most when they fork, patch or extend a platform. With Lago, modifications to the AGPLv3 core are the main concern, especially if the modified service is offered to users over a network. With Kill Bill, Apache-2.0 places lighter conditions on modifications, but your plugin code is a separate artifact that needs its own license decision. Engineers should decide early where internal changes live, how they track upstream releases, and who reviews dependencies that come with each build.
- Forks and patches: Keep a register of every change to Lago's core code, and have counsel confirm which changes could trigger source disclosure under AGPLv3.
- Plugin code: Kill Bill plugins are deployed as JARs next to the server, so license your plugin code deliberately and check the licenses of its dependencies.
- Upstream tracking: Keep patches small and rebase them on tagged releases. Lago's self-hosting guidance recommends pinning the last tagged version, and Kill Bill's latest release in the 0.24.x line is 0.24.22.
- Contribution terms: Read each project's contribution rules before sending patches upstream, since contributed code may carry terms you have not agreed to.
Before the first release of a modified build, confirm with counsel how internal changes and plugin code fit each license.
Teams that deploy unmodified software face fewer copyleft questions, but license duties still apply. Running an unchanged build inside your own infrastructure is simpler than changing it, yet operators still have to preserve license notices, track third-party components in container images and understand what the vendor does and does not promise. For Kill Bill, the most important practical point is that the license includes no support or SLA, so incident response depends on your own team or on a paid arrangement. Lago's free edition has its own boundaries, and operators should know which features sit behind an Enterprise plan before they design around them.
- Internal use: Running unmodified Lago or Kill Bill inside your own environment generally keeps copyleft questions narrow, but confirm with counsel that your use stays internal.
- Notices and images: Keep license notices in your container images. Kill Bill's Docker setup uses the killbill/killbill, killbill/kaui and killbill/mariadb images, so inventory each one.
- Support gap: Kill Bill's license provides no support or SLA, so decide who answers incidents at 2 a.m. before go-live.
- Enterprise features: Confirm which features require an Enterprise plan and whether that plan includes support, since the AGPL does not answer that question.
Ask each vendor and partner to list in writing what is covered by support and what remains community-only.
Hosting a billing platform for customers raises the sharpest license question. Running a platform for your own finance team is one case. Making a modified billing service available to customers, including through a web interface or API, is another. AGPLv3 treats network use as a potential trigger for source obligations, so a hosted, modified Lago deployment needs careful review. Kill Bill's Apache-2.0 license permits commercial hosting, subject to notice and attribution duties. Lago also offers a managed option, Lago Cloud, which changes who operates the service but does not change the terms of the self-hosted license.
- Unmodified hosting: Offering an unmodified AGPL build to customers is a different question from offering a modified one, so document which applies.
- Modified hosting: Changes made available to customers over a network typically require source availability under AGPLv3. Confirm the exact scope with counsel.
- Apache-2.0 hosting: Kill Bill's license permits commercial hosting with notice and attribution. It does not supply support or an SLA for your customers.
- Trademarks: The Billing Project, LLC owns the Kill Bill codebase and trademarks, so review any use of those names in your product or service branding.
Get a written opinion from counsel covering hosting, modifications and customer terms before you launch.
What drives the running cost of each billing engine
Running either engine costs more than its license line, which is zero for both. The cost sits in the services you operate, the people who keep them upgraded, and the integrations and editions you add. The cards below separate one-time setup work from recurring operating cost so you can ask every vendor and partner for the same breakdown.
Infrastructure you operate
Lago's Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, with ClickHouse optional and disabled by default. Kill Bill runs as a WAR in Tomcat backed by a database, with plugins deployed alongside it. Both bill recurring infrastructure cost. Ask for the sizing assumptions behind each service and whether ClickHouse or a larger database tier is included in the quote.
Engineering skills to keep it running
Lago's operating skills center on Docker and PostgreSQL, with Ruby knowledge needed for deeper troubleshooting. Kill Bill requires Java, Tomcat and JDK 11 for the Tomcat install path, plus a database team familiar with MySQL or MariaDB. Staffing is the largest recurring line for most in-house teams. Ask the partner which skills the quote assumes and whether knowledge transfer is a one-time deliverable or ongoing.
Upgrades and version pinning
Lago's docs recommend pinning the last tagged version rather than the latest image tag, so every upgrade becomes a planned change with testing. Kill Bill's core, Kaui and plugins each need compatible versions. Upgrade testing against your own invoices and payment flows recurs with every release. Ask whether the quote includes upgrade testing, rollback planning and regression runs against your plugins.
Support and service levels
Kill Bill ships under Apache-2.0 with no support or SLA included, so any production support must come from a commercial agreement with a vendor or partner. Lago offers Enterprise plans for premium features, and its support terms are set by that contract. Compare response commitments in writing rather than assuming they match. Ask whether support is a fixed monthly retainer, billed by incident, or bundled with upgrades.
Paid Enterprise features
Lago's free edition covers fundamental billing, while Enterprise plans add premium features. Those features are a recurring license cost that sits on top of infrastructure and staffing. Kill Bill's plugins are open source, but payment gateway, tax and fraud connectors can still require build or license work. Ask which features you need, whether they are in the Enterprise contract, and how renewal pricing is set.
Integration work and the one-time build
Lago's README lists NetSuite, Xero, Salesforce and HubSpot integrations, and a payment processor such as Stripe, Adyen or GoCardless must be connected separately. Kill Bill connects gateways through plugins that you configure and test. Most of the one-time spend goes into mapping your product catalog, tax rules and ledger exports. Ask for a fixed-scope deliverable list covering each integration and the test evidence delivered at the end.
Moving billing from Kill Bill to Lago or the reverse
This sequence moves a live billing book between the two platforms without a gap in invoicing, so each customer is billed exactly once and every open balance is accounted for. The result is a documented cutover with reconciled invoices, working payment collection and a clear rollback point.
Inventory the current billing configuration
Export the Kill Bill catalog (products, plans, phases, prices and usage-based units) and the Lago or Kill Bill configuration you will target, including billable metrics, plans and charge models. The owner is your billing engineer with finance sign-off on the pricing rules. Done means every active plan has a written mapping to a target object, and any plan that has no equivalent is flagged for a decision before data moves.
Export customers and active subscriptions
Extract accounts, billing addresses, tax identifiers, subscription start and end dates, billing cycle anchors, add-ons and any pending plan changes from Kill Bill through its REST APIs. Store the extract in a staging database with a checksum. Done means a row count per entity matches the source, and a sample of accounts has been compared field by field against the Kill Bill admin view in Kaui.
Map plans to Lago metrics or Kill Bill products
Translate each Kill Bill recurring plan into a Lago plan with fixed and usage charges, and translate each usage-based Kill Bill unit into a Lago billable metric with the same aggregation logic. Where the two engines model proration, trials or credits differently, record the difference as a decision. Done means a signed mapping document exists, and test invoices for representative accounts match expected amounts in staging.
Migrate open invoices, credits and balances
Load unpaid invoices, account credits and prepaid balances into the target system as opening balances, with original invoice numbers kept as external references so customers and auditors can trace them. Finance reconciles totals by account and by currency. Done means the sum of opening balances in the target equals the sum of open items in the source, with any gap explained line by line.
Move gateway tokens and reconfigure webhooks
Kill Bill and Lago both delegate card collection to an outside payment processor, and Lago names Stripe, Adyen and GoCardless as supported providers. Vaulted payment methods usually cannot be copied between accounts, so the gateway must cooperate through token migration or a controlled re-consent flow. Reconfigure webhooks to point at the new system and confirm signatures. Done means a test payment succeeds through each gateway and payment status events land in the new system.
Run parallel invoicing and reconcile outputs
Run both systems for one full billing cycle on the same usage data, with only one of them allowed to charge customers. Compare generated invoices, tax lines, usage totals and payment outcomes for every account. Done means differences are either zero or documented with a cause, and finance has signed off the variance report before cutover is scheduled.
Cut over and keep a rollback path
Freeze Kill Bill subscription changes, take a final usage and subscription snapshot, switch the billing scheduler and gateway webhooks to the new platform, and confirm the first live run. Keep the Kill Bill environment read-only for the agreed retention period, which your compliance team should confirm. Done means the first live invoice run completes, reconciliation passes on day one, and the rollback decision owner has written criteria.
Document what was rebuilt and what transferred
Record which elements moved as data, which were rebuilt as configuration or code (such as custom Kill Bill plugins, which have no direct Lago equivalent and need separate integration work), and which required gateway or accounting-system action. Done means a handover document lists each item with its owner, and the rebuilt integrations have passed the same test cases as the originals.
Where billing implementations usually run long
Plan the deployment effort around configuration, not installation. Lago's self-hosted path is a Docker Compose stack that runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, with ClickHouse disabled by default. Standing that stack up is usually the quick part. The longer work is sizing the workers for your event volume, pinning the last tagged release as the self-hosting docs recommend instead of the latest image tag, and wiring the payment gateway so that Lago's calculated charges reach Stripe, Adyen or GoCardless. Larger deployments move to the Helm charts and dedicated workers the docs describe, which adds a Kubernetes skill requirement. Confirm with your platform team who owns upgrades between tagged versions, since Lago releases move quickly.
Kill Bill's effort sits in a different place. The server is a WAR file typically run in Tomcat, the installation guide requires JDK 11, and each payment, tax or fraud integration is a plugin JAR that has to be deployed into the same environment and configured. Much of the early work is the catalog: products, plans, price lists and phases must be modeled in configuration before invoices can be trusted, and Kaui, the back-office UI, needs its roles set up for support, product configuration and finance reporting. Kill Bill's getting started guide notes that the core team tests against MySQL, MariaDB 10 and PostgreSQL 12, so confirm that your chosen database is in use by other adopters before committing to it.
Across both platforms, the delays that most often push timelines out are the same: tax rules, gateway webhooks, invoice templates and data mapping from the source system. Tax logic depends on which jurisdictions and tax providers you must support, and neither platform removes that analysis. Webhook handling from the gateway must be tested for retries, duplicates and out-of-order delivery before any live charge runs. Invoice templates need legal and finance sign-off, and customer, product and usage identifiers must map cleanly from your CRM, ERP or metering data. Ask any implementation partner to write these four items into the fixed scope, with named owners and acceptance tests, so that they are not discovered during cutover.
Questions buyers ask before hiring help with billing
What drives the cost of running Lago or Kill Bill?
Cost is driven by the people and services around the software, not the license fee, since both projects are free to download. Lago is licensed under AGPLv3 and Kill Bill under Apache License 2.0, so neither charges a license fee for the core. The recurring costs are the infrastructure you run, the engineers who maintain it, and any paid payment gateway or support contract you choose. For Lago, the stack is a front end, an API, workers, PostgreSQL, Redis and Gotenberg, plus optional ClickHouse for high event volumes. For Kill Bill, the stack is a Java WAR in Tomcat, a supported database such as MySQL, plugins and the Kaui back office. Ask any quote to separate one-time setup from recurring operations, and to name who pays for each piece.
Can an internal team run Lago or Kill Bill without a partner?
Yes, if your team has the skills to operate the components and the time to keep them patched. Both are open source, so you can deploy them yourself without buying a license. 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, which means someone must own upgrades and capacity. Kill Bill's getting started guide requires JDK 11 for the Tomcat installation, and its core team tests against MySQL, MariaDB 10 and PostgreSQL 12, so your database and Java operations need an owner. Be realistic about the gap: Kill Bill includes no support or SLA by default, so an internal team carries the full burden of incident response. Decide who holds that responsibility before you choose.
What does the work need from engineering and finance?
Engineering owns the deployment, integrations and data flow, while finance owns the rules that determine what is charged. On the engineering side, expect work on the payment gateway connection, since Lago needs a separate processor such as Stripe, Adyen or GoCardless, and Kill Bill connects to gateways such as Stripe, Braintree and PayPal through plugins. Expect integration work for accounting and CRM systems, which Lago lists as NetSuite, Xero, Salesforce and HubSpot. On the finance side, pricing models, tax treatment, invoice formats, credit rules and dunning policy need written decisions before build starts. Kill Bill's Kaui back office gives internal teams role-based access for support, product configuration and finance reporting, which can shift some of that work to finance staff. Ask any partner to name these responsibilities in the written scope.
How long should we plan for a billing implementation?
Plan in phases tied to decisions, not to a fixed number of weeks. The duration depends on how many products and pricing models you need, how many gateways and accounting systems must connect, how much historical data must migrate, and how many approvals sit inside finance and tax. Lago's model of metering events, applying pricing and producing invoices means usage data quality often sets the pace, so validate event pipelines early. Kill Bill's subscription model, with upgrades, downgrades, invoices and credits, often takes longer to define in the product catalog than to deploy. No researched figure is available for either project, so ask each vendor or partner for a phased plan with milestones and the assumptions behind each one, and check that the timeline lists its dependencies on your own environment.
What support does Kill Bill lack by default?
Kill Bill ships without support or an SLA, so vendor-backed response times, guaranteed fixes and contractual uptime are not part of the default package. The project is open source under Apache License 2.0 and has been in production since 2010, but the README states that no support or SLA is included. The Billing Project, LLC owns the codebase and trademarks, which is useful for licensing clarity but does not replace an operational support contract. Plugins for gateways, tax and fraud are also deployed as JARs in your environment, so compatibility after upgrades becomes your responsibility unless a contract covers it. Ask any provider what they will monitor, how they handle incidents, and which parts of the plugin estate they will maintain.
When is a managed or paid option worth comparing?
A managed or paid option is worth comparing when your team cannot staff the operational load or when a feature you need sits behind a paid tier. Lago offers a forever-free open-source edition with fundamental billing features, and Enterprise plans that add premium features, so check whether dunning, tax or accounting integrations you need are in the free scope. Lago also documents Lago Cloud as a managed option, which removes the need to run workers, PostgreSQL and Redis yourself. For Kill Bill, a paid support or hosting arrangement from a provider would fill the support gap described above. Compare the managed cost against the internal hours, on-call duties and upgrade risk it removes, using the same written scope for each option.
Which license terms should legal review before we pick one?
Legal should review how each license applies to your deployment and to any changes you make. Lago's platform is licensed under AGPLv3, which carries source disclosure obligations for network-accessed modifications, while its agent SDKs and MCP server are MIT licensed in separate repositories. Kill Bill is licensed under Apache License 2.0, which is permissive and does not carry the same network disclosure duty. Confirm with counsel how the AGPL-3.0 terms interact with your planned customizations and internal-only use. Do not treat this summary as legal advice; confirm the terms with your legal team before you build on either platform.
How do we check the scope of a fixed-scope billing engagement?
Check that the written scope lists systems, deliverables, acceptance criteria and exclusions before any work starts. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the gateway and accounting integrations named one by one, the data migration approach, the test and cutover plan, and who owns runbooks after handover. Ongoing support, upgrades and testing are available as retainers, which should be priced separately from the build.
How to test both platforms against your own billing data
Run a short bake-off before you commit, using your own billing data rather than vendor demos. Load a representative product catalog into both Lago and Kill Bill: include your real billable metrics, plans with usage-based and flat-fee charges, and at least one add-on. On the Lago side, check how billable metrics and charges map to your pricing. On the Kill Bill side, check how catalog XML or API-defined plans, phases and price lists map to the same offers. Record every place where you had to reshape a model to fit the tool, because those gaps tend to become custom code later.
Next, replay a sample of usage events drawn from production, including late-arriving and duplicate events, and compare the invoice totals each platform produces against your current figures. Lago ingests usage through its events API, so confirm how it handles idempotency and event timestamps. Kill Bill has no native metering engine in the same sense, so usage is typically aggregated upstream and pushed in as usage records, which changes where your reconciliation logic lives. Then test one gateway webhook end to end: configure a sandbox account with the processor you actually use, trigger a failed payment, and verify that the event reaches the platform, updates the invoice state and retries correctly. Confirm which gateway integrations each product supports for your region and processor, because Lago names Stripe, Adyen and GoCardless in its documentation, while Kill Bill's documentation names Stripe, Braintree and PayPal.
Finally, test one mid-cycle plan change that triggers proration, such as an upgrade on the 15th of a billing period with a credit for unused time, and check the resulting invoice line items, credits and tax treatment against your accounting rules. Then record what each stack needs to operate: the services to run (Lago's Docker Compose deployment includes PostgreSQL, Redis and Gotenberg, plus optional ClickHouse; Kill Bill runs as a WAR in Tomcat with a MySQL, MariaDB or PostgreSQL database and JDK 11 per its getting started guide), who on your team can restart, upgrade and debug each one, and how long a version upgrade took in a staging copy. Results depend on your data volumes, processors, tax jurisdictions and infrastructure, so treat this as a method to run in your own environment, not as a benchmark.
How DeployOpen helps choose, implement or migrate billing
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For billing, that means working out which engine fits your pricing model and payment setup, then building it in your environment with the evidence your finance and compliance teams need.
How we scope
- Confirm which pricing models you need: usage metering, recurring plans, or both, before choosing an engine.
- Map your payment gateways, tax, accounting and CRM systems to the integrations each platform actually supports.
- Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope.
How we build
- Deploy the chosen platform in your infrastructure, pinning a tagged release and documenting the services that run.
- Connect the payment gateway and downstream systems, then test invoices, credits and plan changes against your own rules.
- Harden access, secrets and backups, and set up the logs and tests your security and finance reviewers will ask for.
How we hand over
- Deliver architecture notes, runbooks, upgrade steps and configuration documentation your own team can operate.
- Walk your engineers and finance operators through the back-office tools and the billing lifecycle end to end.
- Provide the evidence and control documentation your compliance team needs, without issuing any audit report or certification.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
- Plan version upgrades and test them in staging before they reach production billing runs.
- Ask for a quote based on the written scope, so cost follows from the agreed work rather than a published price list.

