Stripe Billing or self-hosted Lago: which fits when Stripe stays as the processor?
If you keep Stripe for card acceptance and want plans, metering and invoices out of Stripe, the choice is about who runs the billing logic. Stripe Billing fits best when your team has little capacity to operate another system, when one vendor for payments and billing is the simpler control to own, and when your pricing sits comfortably inside what Stripe supports. Lago fits when billing data and pricing rules must stay in your own infrastructure for residency or contractual reasons, or when the percentage-of-volume fee on billing is the cost you want to remove. Lago is a separate service that calculates what to charge and when, then hands the charge to a payment gateway such as Stripe, so the processor relationship continues unchanged.
The decision turns on three questions. First, operating capacity: Lago's Docker Compose stack runs an API, workers, PostgreSQL, Redis and Gotenberg, and someone must patch, back up and upgrade it, so ask who owns that on-call and how often you can take upgrades. Second, data control: list which billing records, customer attributes and invoice data must remain on your servers, and confirm that your payment design keeps card data out of Lago. Third, feature fit: map each pricing model you use today (plans, add-ons, usage charges, credits, coupons, tax handling) against Lago's documentation and the open-source edition's scope, and note which items the Lago FAQ places in its Enterprise plans. Any gap on that list is a cost to price before you decide, not after.
Which option fits which buying situation
This table matches common buying situations to the option that usually fits better, Stripe Billing or self-hosted Lago. Read each row as a condition: the advantage only matters when the situation in the first column applies to your organization. Stripe remains the payment processor in every row, so the decision is about who runs billing logic and where invoice data lives.
| Scenario | Better fit | Why |
|---|---|---|
| No platform engineers, and billing should be run by the payment vendor | Stripe Billing | Lago needs a team to run Postgres, Redis, workers and upgrades. If nobody will own that work, the managed service is the lower-risk choice. |
| Invoice and customer billing data must stay on your own servers | Lago (self-hosted) | Lago runs in your infrastructure, so subscriptions, invoices and usage records stay with you. Confirm with your data protection and compliance owners which records count as in scope. |
| Usage-based product with high event volumes | Depends on load, test first | Lago's event pipeline can use optional ClickHouse storage, which is disabled by default. Load test your expected event rate before committing, and compare with Stripe's metering limits in writing. |
| Team already runs PostgreSQL, Redis and containers | Lago (self-hosted) | Lago's Docker Compose stack uses PostgreSQL, Redis, Gotenberg and its own workers. Existing skills and monitoring lower the operating load. |
| Renewal or fee change is the trigger for review | Lago (self-hosted), after a cost comparison | A percentage-of-volume fee grows with billing volume. Model your current and projected volume against Lago's edition terms, infrastructure and migration effort before deciding. |
| Billing rules change often and need custom code | Lago (self-hosted) | Owning the metering and pricing logic lets your engineers change plans and invoicing without waiting on vendor releases. Plan for ongoing testing of each change. |
What moves out of Stripe Billing and what stays with Stripe
The key point is that Lago splits the job in two. Lago calculates what to charge and when, then hands that charge to a payment gateway. Its FAQ states that businesses using Lago need a separate payment processor, and the README names Stripe, Adyen and GoCardless as supported providers. In practice, this means Stripe can keep accepting cards, storing payment methods and moving money while the billing logic (plans, prices, meters, subscription state and invoices) runs in Lago. Stripe remains the processor you already pay, and the percentage-of-volume charge for billing is what you stop paying.
What moves to Lago is the billing logic: plan and price definitions, metering from usage events, the subscription lifecycle (trials, upgrades, proration and cancellations), and invoice generation with PDF output, which Lago's Docker Compose stack produces through Gotenberg. Dunning, the retry and reminder logic for failed payments, moves only if you configure it in Lago. Stripe's own retry rules may still run for charges sent to Stripe, so decide one owner for each retry path before cutover. What stays with Stripe includes card acceptance, card token storage, the dashboard for disputes and refunds, and the payment records that your processor holds. Confirm with your Stripe account team which of these you will still operate in the Stripe dashboard and which you will drive through its API.
Two integrations need a decision now. Lago's README lists connectors for NetSuite, Xero, Salesforce and HubSpot, so check whether your accounting ledger and CRM are among them, and whether the connector covers the invoice and customer fields you rely on. If a tool you use is not on the list, plan for a custom sync or a change to your month-end process. Also confirm which team owns the link between Lago's customer records and Stripe's customer IDs, because that mapping is what prevents double charges during the move.
Capabilities side by side: Stripe Billing and Lago
This table compares what Stripe Billing and Lago each cover, with Stripe kept as the payment processor in the Lago scenario. Read each row as a question about where the billing logic sits, and confirm any Stripe detail marked for checking against current Stripe documentation before you plan around it. The main takeaway is that Lago takes over pricing, metering and invoice calculation, while a payment gateway still collects the money.
| Capability | Stripe Billing | Lago |
|---|---|---|
| Subscription and usage billing | Hosted subscription and usage billing inside Stripe, priced as a share of billing volume | Open-source monetization infrastructure for subscriptions and usage-based pricing, self-hosted in your environment |
| Metering | Usage metering within Stripe Billing; confirm event limits and metered price types in Stripe documentation | Meters usage events and applies pricing; optional ClickHouse store for high event volumes, disabled by default |
| Invoicing | Invoices generated and hosted by Stripe; confirm invoice customization options in Stripe documentation | Produces invoices and PDFs (PDF generation through Gotenberg); you control templates and hosting |
| Payment collection | Collects payments natively through Stripe as the processor | Calculates what to charge and when, then sends charges to a gateway such as Stripe, Adyen or GoCardless |
| Accounting and CRM integrations | Confirm connector list in Stripe documentation and app marketplace | Lists integrations with NetSuite, Xero, Salesforce and HubSpot; confirm fit for your ledger |
| Licensing | Proprietary hosted service under Stripe's terms | Core platform under AGPLv3; agent SDKs and MCP server under MIT in separate repositories |
| Deployment model | Stripe-hosted SaaS only | Self-hosted via Docker Compose, or Helm charts for larger deployments; the free open-source edition covers fundamental billing features and Enterprise plans add premium features |
Where your billing data lives and who can reach it
Moving billing logic to Lago changes where subscription, usage and invoice data sit, but card data can stay with Stripe. Each card below covers one decision you need to make about location, hosting, licensing or evidence before you choose the architecture.
Data location and split
Lago stores its application data in PostgreSQL, uses Redis as its job queue, and can add ClickHouse for high-volume events. All of that runs in your environment. Stripe continues to hold customer payment methods and card data on its side. Map each data class to a location and confirm which fields Lago needs to receive from Stripe, such as customer IDs and invoice references, so you do not copy card data by accident.
Hosting model options
The Docker Compose setup runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg for PDF generation. Larger deployments are pointed to Helm charts and dedicated workers. Ask your team who will operate the chosen model, how workers are scaled, and how backups of PostgreSQL are taken and tested. Pin the last tagged release rather than the latest image tag so upgrades are deliberate.
Licence and edition scope
The Lago platform is licensed under AGPLv3, while its agent SDKs and MCP server are MIT licensed in separate repositories. The free open-source edition covers fundamental billing features, and Enterprise plans add premium features. Confirm in writing which capabilities your plan needs, such as the features your invoicing or tax setup depends on, and whether they sit in the free or Enterprise edition.
AGPLv3 network obligations
AGPLv3 can require you to publish source code of modifications when users interact with a modified version over a network. This matters if you customize Lago and expose it to customers or partners through a portal or API. Internal use without network-facing changes is treated differently. Have counsel confirm how the licence applies to your modifications and deployment before you build customer-facing features on top of it.
Evidence for access and change control
You will own the evidence for access control to the Lago admin console and databases, backup restore tests, and change management for each upgrade. DeployOpen prepares these controls and records for assessment, but independent auditors and certification bodies issue any report. Ask your assessor which artifacts they expect, such as access reviews and change tickets, and plan to collect them from the first day of operation.
What you pay for: Stripe's volume share versus running Lago
The cost comparison starts with a fact that does not change in either scenario: Stripe keeps its payment processing fees, because Stripe stays as the payment processor. What you can remove is Stripe Billing's own charge, which is priced as a share of billing volume and grows as your invoiced revenue grows. Ask your Stripe account team or review your current order form to confirm the exact billing line items on your invoices, since that line is the figure your savings case depends on. Do not model the switch on list prices alone. Pull twelve months of actual billing-line charges and compare them against the total cost of the replacement.
On the Lago side, the cost splits into five components. The software is either the forever-free open-source edition, which covers fundamental billing features, or an Enterprise plan that adds premium features, quoted separately by Lago. Infrastructure covers PostgreSQL for application data, Redis as the job queue, the API and worker containers, Gotenberg for PDF generation and, if you need it for high event volumes, an external ClickHouse store, which is disabled by default. The migration project is one-time work. Recurring operations are upgrades (Lago recommends pinning the last tagged version rather than the latest image tag), backups, monitoring and on-call coverage. Event volume, the number of environments such as staging and production, and high availability requirements push infrastructure and operations costs up. Larger deployments that move to Helm charts and dedicated workers add operational effort too.
When you request a quote from DeployOpen or any other implementation partner, ask for a written scope that names the Lago edition, the environments in scope, and the migration boundary: which subscriptions, plans, invoices and customers move, and which stay in Stripe. Confirm the support model, including response expectations, who handles upgrades, and whether backup and restore testing is included. Ask how the quote treats the first year of hosting compared with later years. Use that written scope to build a total cost model with the Stripe billing line on one side and infrastructure, migration and recurring operations on the other, and make the decision on that comparison.
What running Lago yourself asks of your team
Running Lago yourself means owning a multi-service stack. 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. Your team deploys and patches each of these, backs up the PostgreSQL database and runs restore tests on a schedule, and watches the clock and API workers, since a stalled clock worker is the kind of fault that delays billing runs without an obvious error on the front end. Gotenberg handles invoice PDFs, so its availability affects whether invoices reach customers. ClickHouse is optional and disabled by default, but if you enable it for high event volumes, it becomes one more component to operate.
Pin the last tagged version rather than the latest image tag, as the Lago self-hosting docs recommend. Upgrades then become deliberate events: read the release notes on the getlago/lago releases page, confirm the current tag when you plan the change (releases ship often, so the tag you read last month may already be superseded), test the upgrade against a copy of production data, and schedule it outside a billing run. Larger deployments should move to the Helm charts and dedicated workers the docs point to, which adds Kubernetes skills to the list. Ask your platform team who will own each of these tasks and how long a rollback takes if an upgrade misbehaves.
Two decisions are organizational rather than technical. First, do you have on-call coverage for billing runs, including the day invoices are finalized and payments are collected through Stripe? Second, who approves changes that affect invoices, such as plan edits, tax settings or webhook changes, and who checks the result before customers see it? If you already operate PostgreSQL, containers and a monitoring stack, you can likely run Lago in-house. If those skills are thin, a retainer from DeployOpen can cover upgrades, continuous support and backup verification, with the scope agreed in writing before work starts.
How a move from Stripe Billing to Lago proceeds
The sequence moves billing logic out of Stripe in controlled stages, so each stage has a comparison of outputs and a single cut-over point, while Stripe keeps processing the payments.
Inventory Stripe billing objects and usage
Export a complete picture of products, prices, subscriptions, invoices, tax settings, coupons, credits and metered usage from Stripe, including the meters and usage records that feed them. Your engineers and finance lead do this together, because finance knows which invoice rules matter and engineering knows which integrations read Stripe data. The step is done when you have a written inventory that lists every active subscription type and every system that reads billing output, such as your ledger, reporting or tax tools. Confirm with your DeployOpen scope which of these items are in the first delivery.
Deploy Lago in a non-production environment
Install Lago in a staging environment inside your own cloud account or data center, using the Docker Compose deployment for evaluation. Pin the platform to the last tagged release rather than the latest image tag, as Lago's self-hosting documentation recommends, and record that version in your change log. Lago needs PostgreSQL, Redis, a front end, an API, workers and Gotenberg for PDF generation, so confirm the hosting and backup design before you connect any real customer data. The step is done when the staging instance runs, its workers process jobs, and a test invoice renders correctly.
Recreate plans, meters and customer mappings
Rebuild your plans, charges and billable metrics in Lago so they match the inventory, then map each existing Stripe customer to its Lago customer record using a stable identifier. The main risks here are proration rules, which can differ between the two systems, and tax configuration, which must be recreated explicitly because it does not carry across automatically. Review each plan with finance against a sample of real subscriptions. The step is done when a documented mapping file covers every active customer and each plan has a sign-off on its pricing logic.
Run parallel invoice generation in a test window
Generate invoices for the same billing period in both Stripe and Lago without collecting payment from Lago, then compare line items, taxes, proration, rounding and totals customer by customer. Also check that reports and exports used by finance and accounting still receive the fields they expect, because reporting breaks are often found only at this stage. Investigate every difference and record its cause. The step is done when the differences are either explained and accepted or corrected, and the reconciliation report has been signed by finance.
Set the cut-over date and switch invoicing
Agree a written cut-over date after which Lago generates invoices and Stripe stops creating or renewing subscriptions for the same customers. Disable the Stripe-side billing automation before Lago takes over, so that no customer receives two charges for the same period, and keep Stripe as the payment processor that collects the amount Lago calculates. Hold a short runbook for rollback in case collection fails on the first cycle. The step is done when the first live Lago invoice run completes, payments are collected through Stripe, and no subscription is billed by both systems.
Retire Stripe billing configuration and verify
After the first full cycles have settled without errors, remove or archive the Stripe subscriptions, products, prices and meters that Lago now owns, while keeping Stripe's payment configuration, webhooks and customer payment methods that Lago depends on. Confirm that refunds, disputes and failed payment retries follow the path you documented, and update your accounting, tax and data protection records to show where billing data now lives. The step is done when Stripe shows only payment activity, the runbook is closed, and your operations team owns the Lago upgrade and backup routine.
Questions buyers ask before choosing Lago over Stripe Billing
How much effort does a migration from Stripe Billing to Lago take?
The effort depends on the size and shape of your billing data, not on a fixed figure. The main drivers are the number of plans and add-ons you must recreate as Lago plans and charges, the number of billable metrics (meters) you must define so usage is counted the same way, the number of customers and active subscriptions you must link, and how much invoice history you need to carry over. Whether historical usage must be backfilled into Lago is often the largest single driver, because it means reconciling past events against past invoices. Ask any provider to split its estimate by these items, and to show how it will verify that no customer is charged twice during the cutover.
Can our team migrate to Lago without outside help?
A capable in-house team can do it if it has three skill sets: PostgreSQL administration, container operations for running Lago's services, and billing-domain knowledge covering proration, tax, credits and dunning. The answer changes with the integrations in scope. Connecting Lago to Stripe for payment collection, and to an accounting system such as NetSuite or Xero, or to a CRM such as Salesforce or HubSpot, adds mapping work and failure modes that need someone who has done it before. Assess honestly where your skills are thin, and treat the cutover plan and reconciliation as the parts most worth an external review.
How long does a Lago implementation take?
There is no standard duration that applies to every organization, so do not accept one from a vendor without seeing the scope behind it. Timelines follow from the number of products, the volume of historical data, the integrations in scope, the testing you require and whether you run a parallel period before switching invoice generation. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written plan that lists each phase, its entry and exit criteria, and the dependencies on your payment and finance teams.
Do we have to replace Stripe if we move billing to Lago?
No. Lago is a monetization layer, not a payment processor. It meters usage, applies pricing, produces invoices and manages payment collection, then sends the charge to a payment gateway. Its documentation names Stripe, Adyen and GoCardless among supported providers, so Stripe can remain your processor while Lago calculates what to charge and when. Keep in mind that this changes which system owns subscription logic and invoice generation, so you must decide during planning which Stripe objects you retire, which you keep, and how card tokens and customer records are referenced after the switch.
What does the free Lago edition lack compared with Enterprise?
Lago offers a forever-free open-source edition that includes fundamental billing features, and Enterprise plans that add premium features. The exact feature split is set by Lago, and it can change, so confirm it against the current feature list in the Lago FAQ before you build a plan around it. Check every capability your business relies on, such as specific invoicing, tax, reporting or access-control features, and ask Lago in writing whether each one is in the open-source edition. Licensing also matters: the platform is AGPLv3, which your legal team should review against how you plan to modify and distribute it.
What does a DeployOpen retainer cover after go-live?
A retainer is an ongoing arrangement for support, upgrades and continuous testing after the initial implementation. For Lago, the practical work usually includes upgrading to newer tagged releases, which Lago's self-hosting guidance recommends pinning rather than tracking the latest image, reviewing configuration as your event volume grows, and checking backups and restore procedures. Scope, response expectations and frequency are set out in the written agreement, so ask what is included, what is excluded and how change requests are priced before signing. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen works on this
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 a Stripe Billing to Lago evaluation, we start from a written scope that keeps Stripe as the payment processor and defines exactly which billing logic moves to Lago.
How we scope
- Written scope agreed before work starts, covering which plans, meters and invoice flows move to Lago
- Inventory of existing Stripe subscriptions, usage metrics and invoice templates that need to map across
- Decision on whether Stripe remains the payment gateway and how Lago connects to it
- Confirmation of the Lago edition and any Enterprise features your billing rules depend on
How we build
- Deploy Lago in your own infrastructure using the Docker Compose or Helm approach your environment supports
- Pin a tagged Lago release rather than the latest image tag, and document the upgrade path
- Integrate Lago with your Stripe payment setup, ERP or CRM connections, and internal systems in scope
- Test metering accuracy, invoice generation and payment collection in a staging environment before cutover
How we hand over
- Runbooks for backups of PostgreSQL, Redis and stored invoice PDFs, plus restore tests
- Documentation of the Stripe to Lago cutover steps, including how existing subscriptions avoid double charges
- Configuration, access and security control evidence organized for your compliance assessors
- Knowledge transfer sessions with your platform and finance operations teams
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer
- Upgrade planning for new Lago releases, with changes tested before they reach production billing
- Operational support for worker queues, event volume growth and optional ClickHouse storage decisions
- Ask us to confirm the support scope, response expectations and retainer terms in your written quote
