Product feedback

Customers cannot currently associate a one-off invoice with a specific plan. As a result, exported one-off invoice data cannot be grouped or analyzed by plan without manual adjustments. Add an optional plan association when creating a one-off invoice through the UI and API. Include the associated plan in relevant invoice exports. This association should be reporting metadata only. It should not cause the invoice to inherit the plan’s pricing, charges, or subscription behavior.

Although billing data can be retrieved via the API, Finance teams need to visualize and export data from the API. This is highly important for revenue recognition reporting purposes.

## Context First of all, congratulations to the Lago team — it’s one of the most robust and transparent open-source billing platforms available today. However, deploying Lago self-hosted is still complex and time-consuming, especially for users who want to run it on modern PaaS platforms — both self-hosted and managed cloud solutions . I’ve personally tried to deploy Lago multiple times, even with step-by-step help from ChatGPT, and still couldn’t get it running properly . Most of the issues were related to environment variables, RSA key formatting, and networking between containers ( api , front , worker , clock , pdf , postgres , redis ). Today, many developers use platforms like: ### 🧩 PaaS Self-Hosted Coolify Cloudfy EasyPanel Dokku — GitHub Dokploy CapRover Portainer Tipi Yacht ### ☁️ PaaS Hosted (Managed) Railway Vercel Netlify [ Fly.io ]( https://fly.io ) Orion Ploi These tools have become the modern standard for developers who want “self-hosted Heroku-like” experiences — a simple, visual way to deploy Docker-based applications in production environments. Unfortunately, **Lago currently doesn’t provide an official docker-compose.yml or manifest optimized for these deployers**, which makes installation difficult even for experienced users. --- ## The problem The current documentation focuses on local Docker setup and manual orchestration. There’s no verified YAML definition for external PaaS or automated deployers. Lago’s multi-service stack — api , front , worker , clock , pdf , postgres , and redis — requires precise networking and environment configuration. Variables like LAGO_RSA_PRIVATE_KEY (multiline PEM) and LAGO_API_URL are especially error-prone when set inside UI-based deployers. Common issues include: - API container crashing due to RSA key parsing errors; - Worker and clock services restarting endlessly; - Frontend failing to connect to the backend; - Health checks failing even when containers are technically running. --- ## Why it matters An **official, deployer-friendly docker-compose.yml ** would: Enable one-click deployment on platforms like Coolify, Dokku, CapRover, and Railway; Reduce onboarding friction and YAML misconfigurations; Make Lago more accessible to small SaaS teams, indie devs, and startups that use PaaS tools; Increase adoption among self-hosted users who prefer visual or low-code deployers; Strengthen Lago’s ecosystem as the open-source alternative to Stripe Billing that anyone can run in production. --- ## Suggested improvements **Provide an official docker-compose.yml ** optimized for external deployers (not just local development); Include an example .env with: - Proper variable formatting; - Comments explaining multi-line secrets (e.g., LAGO_RSA_PRIVATE_KEY ); - URL guidance for internal vs. external routing; Add short documentation or notes about deploying Lago in self-hosted PaaS platforms; Optionally, verify the setup on at least one environment (Coolify, Dokku, or Railway). --- ## Closing thoughts Lago is an amazing open-source project that deserves a smoother deployment experience. Offering a **ready-to-use YAML and .env example** compatible with self-hosted and cloud PaaS environments would dramatically lower the barrier to entry — helping more developers successfully self-host their billing systems. Thank you for considering this request and for building such an impactful open-source project.

Add a “Send invoice email” option to the custom void/regenerate flow, enabled by default. When disabled, Lago should not send the invoice.finalized notification email for the regenerated invoice. This suppression should apply only to that specific operation, including invoices finalized asynchronously through a tax provider. Currently, the only workaround is to temporarily disable invoice.finalized emails at the billing-entity level, which can unintentionally suppress notifications for other invoices finalized during the same period. Existing behavior should remain unchanged when the option is enabled or omitted.

As a user, I want to be able to define a billing interval for the subscription fee and each charge. The yearly plan currently supports monthly charges, but we would need more flexibility. For instance, for plan A: Yearly subscription fee; and Usage-based charge X billed quarterly. Another example for plan B: Monthly subscription fee; Usage-based charge X billed monthly; and Usage-based charge Y billed quarterly.

Can we get more customization on the export invoices under invoices? I'd like to be able to see customer name in the Advanced export as well as the current Plan that a customer is on - this is more important now that we have our enterprise customers in billing. The use case here is that i'm trying to make sure we export the enterprise invoices from lago and import them into QBO

I can´t seem to find a way to associate entitlements for add-ons. I want customers that have purchased add-ons to receive specific entitlements. Is this something that would make sense or am I misunderstanding the concept of add-ons?

Once a billable metric is attached to a plan, only its name and description can be edited. Calculation and display properties like rounding function, rounding precision, aggregation expression, and unit label are locked. The only workaround is to delete and recreate the metric under the same code

On one-off invoices, the unit price is limited to 2 decimal places because it's stored/entered as whole cents (unit_amount_cents, integer). Line total is computed as unit_amount_cents × units, rounded. For partial-period / prorated charges, the true per-unit price is often fractional (e.g. $0.1467/unit), so we can't produce a line that hits the exact total while keeping the unit price honest. Current workarounds that are incomplete: Decimal units (e.g. 102.3 units) — hits the exact total, but they read "units sold" off the invoice into their internal reporting, so fractional units corrupt the numbers. Second "proration adjustment" line to carry the remainder. This produces the exact total with clean integer units, but looks weird to end customers.

Wallet and prepaid credits currently only apply to subscription invoices. To redeem credits against a one-off invoice today, users have to handle the bookkeeping themselves: create the invoice, manually deduct the amount from the wallet, and keep their own record linking the two transactions.