Self-hosted or managed billing: who runs it and where your data lives
Last updated: November 2026
Should billing be self-hosted or managed?
What each model means
Vendor-managed billing (SaaS)
The vendor runs the billing software on its own infrastructure. You use it through a web interface and an API. Your customers, subscriptions, invoices and payment records are stored in the vendor's databases. The vendor takes care of hosting, upgrades, backups and uptime. Pricing varies by vendor: some charge a share of billed revenue, others charge per transaction, per user or a fixed fee.
Self-hosted billing
You install the billing software in your own cloud account or data center and run it like any other service your team owns. The billing data sits in a database you control. You decide when to upgrade and who can reach the system. The software may be open source or commercial. Some products combine an open source core with paid add-ons.
A mix of the two
Some products split the work. The billing engine and its data run in your infrastructure, and the vendor hosts supporting services such as sign-in, a management console or software downloads. If you look at a product like this, ask which data each hosted service stores.
How the two models compare
Each row is a question your team will ask sooner or later. The answers describe the usual case. Vendors differ, so ask each one to fill in this table for its own product.
| Question | Vendor-managed SaaS | Self-hosted |
|---|---|---|
| Where the data lives and who owns it | In the vendor's databases, in the regions the vendor offers. Your contract sets the rules for ownership, export and deletion. | In your database, in the account and region you choose. You control every copy, including the backups. |
| Who operates and upgrades it | The vendor. Upgrades arrive on the vendor's schedule, and you adapt your integration when the API changes. | Your team. You deploy, monitor, back up, patch and upgrade the system, and you pick the timing. |
| Security review scope | You review the vendor's controls, including its subprocessors and staff access to your data. You cannot inspect its systems directly. | You review the software and your own deployment. If the code is open source, your team can read it. Access to the network and the database stays under your own controls. |
| Cost model | A subscription that includes hosting and operations. It may grow with billed revenue, transaction count or users. | A license fee, or none for open source. On top of that you pay for hosting and for the people who run the system. |
| Customization | Configuration and the extension points the vendor exposes. Changes to core behavior depend on the vendor's roadmap. | Configuration, plugins and, with open source, the code itself. You maintain any changes you make. |
| Exit and lock-in | You export the data and rebuild your integrations elsewhere. Check the export format and what happens to your data after the contract ends. | The data is already in your database. Dropping a commercial add-on can still take work, so check what keeps running without it. |
| Team you need | People who configure plans and prices and integrate the API. Nobody on your side runs servers. | The same people, plus engineers who can run a production service and its relational database, including on-call when something breaks. |
When managed billing is the better choice
- You have no team to run a production service and its database, and you do not plan to hire one.
- Your billing is fairly standard, for example a few plans billed monthly or yearly and paid by card.
- You need to start billing soon and cannot spend time on infrastructure first.
- Your security and legal teams accept billing data stored by a vendor, in the regions it offers.
- You prefer to pay a vendor to be on call for billing.
If most of these describe you, start with a managed service. You can revisit the choice later, when your volume, your data rules or your pricing change.
When self-hosted billing fits
- Billing data has to stay in your own database, account or region, because of a contract, a regulation or your own policy.
- Your security team wants to read the code and control who can reach the system and its data.
- Your pricing needs changes to how the billing engine behaves, beyond what configuration allows.
- Billing is central to your product and you want to decide when it is upgraded.
- You already run production services and databases, so one more is a known cost.
- You want software pricing that does not grow with what you bill. Compare a fixed fee with a percentage of revenue.
Budget for the people and the infrastructure from the start, and decide who handles a production incident at night.
Questions to ask before you choose
- Where is our billing data stored, and in which region? Which hosted services see any of it?
- Who on the vendor's side can access our production data, and how is that access logged?
- How do we export all of our data, and in what format?
- What happens to our data, and to the running system, when the contract ends?
- Who applies security patches, and how do we learn that one is available?
- Can we delay or skip an upgrade?
- What can we change ourselves: configuration, plugins or the source code?
- What does the price depend on, and what does it leave out, such as hosting, operations and payment fees?
- If we self-host, which skills does our team need, and who helps us when production breaks?
Where Kill Bill and Aviate fit
Kill Bill is self-hosted billing and payments software. It is open source under the Apache 2.0 license and has been in production since 2010. You run it in your own cloud account or data center, and the billing data stays in your database. It comes with community help only: there is no support and no SLA.
Aviate is a distinct commercial product built on Kill Bill, and it follows the mixed model described above. Kill Bill and the Aviate plugin run in your infrastructure. The Aviate Control Plane, sign-in and software distribution are hosted by Kill Bill and hold no billing data. Aviate includes Premium support, with an answer within 2 business days for critical production issues. If you stop Aviate at the end of your term, Kill Bill keeps running under Apache 2.0.
To evaluate Aviate, you can use a free sandbox that runs in Kill Bill's cloud. For the price, see the pricing page.