Lago turns usage events into invoices and payments
Lago sits between a product and its revenue operations. Applications send usage events, which become billable metrics and pricing calculations. The same records feed credits, entitlements, subscription charges, invoices, and payment collection. This is broader than counting API requests. It gives finance and product teams a shared model for prepaid balances, minimum commitments, overages, customer overrides, and recurring fees.
The repository's maintained demo prices 3 sample AI requests by sending separate input-token and output-token events. It then retrieves current usage and retries one transaction to check idempotency. That is a good introduction because duplicate delivery is normal in event systems and disastrous in billing. The demo runs locally through Docker Compose with disposable credentials, then leaves the UI available for inspection until cleanup.
Payment providers stop being the product catalog
Lago keeps metering and pricing separate from Stripe, Adyen, GoCardless, or another payment provider. A team can change a usage formula or credit policy without recreating its business model inside a processor-specific catalog. The REST API, SDKs, webhooks, and UI all work with the same billing records. An MCP server is available from a separate MIT-licensed repository for agent access.
That agent route deserves the same control as a finance console. The README says MCP tools can read and write customers, invoices, usage, payments, credit notes, and coupons, using the permissions of the Lago API key. Limit that key, log tool calls, and keep human approval around sensitive changes. A chat interface does not make an invoice mutation less consequential.
What happened when we ran it
Our sandbox tested the Go project under ./events-processor/, not the whole Lago stack. Installing 314 packages took 46 seconds, and the build succeeded in 74 seconds. The test command ended after 29 seconds with exit code 1: 4 packages passed and 2 failed out of 6. The checkout was commit 0b56915 in a 3-CPU, 8 GB unprivileged Debian container with no secrets.
The failure was at link time. GCC called the system linker, which reported cannot find -lexpression_go; as a result, the processors/events_processor test binary could not be built. The supplied tail also showed the models and utils packages passing. It does not say why that library was absent, so the finding is simply that the documented Go test path did not complete in our fresh environment.
The repository contained 170 files, about 12,045 source lines, and occupied 19.9 MB before installed packages. It had 9 CI workflow files, a Dockerfile, and a tests directory. Those numbers describe the events-processor-focused checkout measured by the lab. We did not run the Rails API, browser application, Sidekiq jobs, Redis, PDF service, a payment provider, or a real invoice cycle.
Production means operating several queues and stores
The source deployment starts with Docker Compose and a generated RSA private key. Persistent use adds storage, SMTP, TLS, object storage, Redis, database settings, and upgrade work. Lago's architecture has a Rails API, scheduled jobs, Redis-backed Sidekiq queues, webhooks, invoices, payments, analytics, and optional dedicated workers. Event streaming can add an events consumer and the Go processor we built.
That separation lets operators scale a hot queue without resizing every service. It also creates more places for work to stall. Queue depth, dead jobs, event lag, webhook failures, invoice generation, and payment synchronization all need alerts. Release v1.52.0 moved the events-processor image toward a multi-architecture build workflow, while pull request 776 notes that CI did not yet use a warm layer cache for its Go module download.
Billing correctness needs scenario tests, not only health checks
Open issue 771 reports a self-hosted v1.45.2 case where extending a free trial from 30 to 41 days across a calendar month produced incorrect invoice periods and dates. The reporter also describes a skipped month and proration based on the old trial boundary. Issue 772 separately reports inconsistent subscription start dates between a grid and detail view for the same case.
Those reports do not prove every Lago version mishandles trials. They do show the kind of acceptance suite a buyer needs: month boundaries, leap days, time zones, trial changes, late events, credits, refunds, retries, and customer-specific prices. Reconcile Lago's output against an independent expected ledger before sending invoices. Billing software can be healthy at the HTTP layer while calculating the wrong period.
v1.52.0 shipped on the day of our research
GitHub showed 10,410 stars, 26 combined issues and pull requests, and a last push on August 26, 2026. Release v1.52.0 was published that day. It included an events-processor filter fix, connector image work, multi-architecture build changes, and a rewritten README. Current issue and release activity support the view that Lago is maintained; the open count is not a count of confirmed bugs.
The core repository uses AGPLv3. Lago's separate agent SDK and MCP projects use MIT, while managed and Premium options have their own commercial terms. Self-hosters should review the license and the default basic analytics collection before deployment. Lago earns a trial when pricing rules are a product capability. The failed 2-of-6 package result means source contributors should first reproduce the expression_go link setup on their own build image.