The open-source billing ecosystem has matured considerably. Lago — released as an open-source Ruby on Rails billing engine — is a legitimate alternative to building billing from scratch and has an active community and regular releases. There are also several other open-source billing libraries, payment abstraction layers, and metering engines available. For a SaaS team evaluating billing infrastructure, the self-hosted open-source path looks attractive: no vendor lock-in, no per-event fees, full control of the code and data.
The "free" in open-source does not mean cost-free. The costs shift from licensing and usage fees to infrastructure, engineering time, and operational overhead. Whether this shift is advantageous depends on the specifics of your situation — and the teams that make this decision well are the ones who account for all three cost categories honestly.
The True Cost of Self-Hosting
A self-hosted billing engine requires its own deployment and infrastructure. A production-grade deployment of Lago (as a reference example) requires multiple services: the Rails API, the background job processor (Sidekiq), a PostgreSQL database, a Redis instance, and optionally a separate analytics database as event volumes grow. These services need to run reliably, be backed up, and scale with your usage.
A minimal production infrastructure bill for a self-hosted billing engine on AWS (as of current pricing in the $-mid tier): a managed PostgreSQL RDS instance (db.t3.medium with Multi-AZ) at roughly $120-180/month, managed Redis (cache.t3.medium) at $40-70/month, and ECS Fargate for the API and worker services at $80-150/month depending on task sizing and the number of availability zones you target. Total: $240-400/month in direct infrastructure costs before data transfer, storage growth, and monitoring tooling.
This is not an argument against self-hosting on cost grounds alone. A managed billing infrastructure at a comparable feature level costs $300+/month at scale anyway. The infrastructure cost delta is roughly neutral, which means the real cost comparison is in engineering time.
Maintenance Overhead: The Hidden Engagement
A self-hosted billing engine isn't a one-time integration. It's an ongoing operational commitment. The categories of maintenance work that engineering teams consistently underestimate:
Version upgrades. Open-source billing engines release new versions with bug fixes, new features, and — critically for billing accuracy — calculation logic improvements. Staying current requires reviewing changelogs, testing upgrades in staging, and deploying carefully. For a team that isn't primarily a billing infrastructure company, this is ongoing investment that doesn't ship features for your actual product.
Data migrations. Billing systems accumulate data — customer records, subscription states, event logs, invoices — and schema migrations must be applied carefully to avoid billing inaccuracies during migration windows. A migration that requires a brief downtime on your billing engine means no invoice generation during that window. A migration with a bug that corrupts the subscription state table is a billing incident.
Incident response. When your billing engine has an incident — a stuck Sidekiq worker, a full disk on the database host, a Redis memory issue — you are on the hook for diagnosis and remediation. If this incident occurs at month-end when invoices are being generated, the urgency is extreme. The on-call burden for a self-hosted billing engine is significant, and teams that haven't experienced it often discover this cost only after their first billing incident.
Feature gaps. Open-source billing engines implement the features their community prioritizes. If your pricing model requires something the OSS engine doesn't yet support natively — a specific aggregation method, a nuanced proration rule, multi-currency support with FX rate locking — you need to either contribute the feature upstream (time investment), fork and maintain a patch (technical debt), or work around it in application code (right back where you started).
When Open-Source Billing Makes Sense
There are legitimate scenarios where self-hosted open-source billing is the right choice.
Data sovereignty requirements. Some enterprise customers or regulated industries require that billing data — which may include customer identity, usage patterns, and contract terms — remain in a specific jurisdiction or cloud environment that the customer controls. If you're selling into European financial services or government contracts with strict data residency requirements, self-hosted billing may be a prerequisite, not a preference.
Deep customization needs. If your pricing model is fundamentally different from what any managed billing platform supports — a complex auction-based pricing mechanism, real-time spot pricing that adjusts by the second, or a billing model tied to proprietary business logic that can't be expressed in a standard pricing engine — building on an open-source codebase that you can modify directly is more viable than adapting around managed platform limitations.
Billing infrastructure as a core competency. If your product is itself a platform where tenants have their own billing logic (a marketplace, a cloud provider, a white-label SaaS), investing in owning the billing infrastructure may be strategically justified. The billing engine is part of your product differentiation, not just a cost of running your business.
We're not saying open-source billing is wrong. We're saying it requires you to have a genuine reason that justifies the ongoing operational cost — and "it's cheaper" is usually not that reason once you account for full engineering costs honestly.
TCO Comparison Over 24 Months
A realistic 24-month TCO comparison for a mid-size SaaS processing 10-50 million events per month:
Self-hosted open-source (Lago or similar):
- Initial integration: ~3-4 engineer-weeks to stand up production infrastructure, integrate into product, and test core billing flows. At a blended engineering cost, roughly $25,000-35,000 one-time.
- Monthly maintenance: 4-8 engineering hours per month for updates, incident response, and capacity management. At average rates, $500-1,200/month ongoing.
- Infrastructure: $240-400/month direct cloud costs.
- Feature development: when your pricing model needs a feature the OSS engine lacks, 1-3 engineering weeks per major feature. Highly variable; assume 2 engineering weeks per year → ~$15,000/year.
- 24-month total: $25,000-35,000 (setup) + 24 × ($740-1,600) (maintenance + infra) + 2 × $15,000 (features) ≈ $90,000-120,000.
Managed billing infrastructure:
- Integration: ~1-2 engineer-weeks for a managed platform with good SDKs. $8,000-15,000 one-time.
- Monthly fee: $300-600/month depending on event volume and features.
- Engineering overhead: ~1-2 hours/month for configuration changes, troubleshooting. $100-300/month.
- 24-month total: $8,000-15,000 (setup) + 24 × ($400-900) (fees + overhead) ≈ $20,000-37,000.
The TCO gap is substantial in the scenarios where the managed platform covers your requirements. The gap narrows significantly if managed platform fees scale with event volume beyond the base tier, or if you have specific feature requirements that the managed platform doesn't support. Run the numbers with your specific event volumes and pricing requirements before deciding.
The most common outcome for teams that start with self-hosted billing is that they migrate to managed billing 18-30 months later, after their first serious billing incident and after pricing iteration velocity has been visibly slow. The migration cost — exporting data, rebuilding integrations, validating that all historical invoices are correctly represented in the new system — is non-trivial. Factoring this potential future migration cost into the initial decision often changes the math considerably.
