Meteroid: an AGPL-licensed billing stack in Rust that ingests usage events without pre-aggregation
Open-source Pricing and Billing Infrastructure 🚀 Subscription management, Invoicing, Pricing, Usage-based billing, Cost limiting, Grandfathering, Experiments, Revenue analytics & Actionable insights
At a glance
- What is it?
- Meteroid is an open-source pricing and billing platform aimed at SaaS, infrastructure and AI companies that need usage-based or hybrid plans. The repository ships metering, subscriptions, invoicing and entitlements in one system, but it self-labels as experimental and is still on v1.0.0 release candidates.
- Who is it for?
- Adopt Meteroid if you are building usage-based or hybrid pricing and would rather run a Rust metering service than assemble one from a general-purpose database and a payment provider's subscription objects. Do not adopt it if you need a stable billing system today, since the newest published release is v1.0.0-rc7 and the project labels itself experimental, or if AGPL-3.0 is incompatible with how you distribute your product.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Meteroid targets: usage events that never reach the invoice cleanly
The README frames the problem as a gap between customer usage and billing, and names the audience directly: engineering teams that have already built and maintained a billing system from scratch, product-led teams that want usage-based or hybrid pricing without that build, and sales-led teams that need quote-to-cash without manual handovers between sales and billing. Those are three different buyers, and the repository tries to serve all of them with one data model.
The interesting part is the word pre-aggregation. Most teams that meter usage end up writing an aggregation layer: a job that rolls raw events into counters, a table that stores those counters, and a reconciliation step when the counter and the invoice disagree. Meteroid's claim is that raw usage events (API requests, tokens, transactions, storage) become billable metrics in real time without that intermediate step. Whether the implementation holds up under your event volume is something only your own load test can answer, but the design intent is clear from the feature list: metering is a first-class subsystem, not a cron job bolted onto a Postgres table.
If your pricing is a single flat monthly fee, none of this matters and you should not run a metering pipeline to collect it.
How the pieces fit: events in, versioned plans, invoices out
The README describes the flow in one paragraph: Meteroid integrates with existing systems through an API, collects usage and interaction data, and that data drives the billing engine, which applies pricing models to produce invoices. The architecture diagram in the repository is referenced as assets/meteroid-schema-4.webp, but the README text does not enumerate the services behind it, so the internal topology cannot be confirmed from the supplied material.
What can be confirmed is the shape of the domain. Billable metrics are the transformation step from raw events to something chargeable. Plans carry pricing and are versioned, and the README states that versioning means pricing changes never affect existing customers unless you want them to. That is the grandfathering mechanism, and it is the single most consequential design decision in the product: it means a plan is not a mutable record but a lineage, and subscriptions point at a specific version. Subscriptions then carry lifecycle operations (upgrades, downgrades, mid-cycle changes, cancellations), and invoices and credit notes are generated from the combination of subscription state and metered usage.
ClickHouse appears in the repository topics, which is consistent with a high-throughput event store sitting behind the Rust ingestion path, though the README does not spell out which component reads from it. Treat the topic list as a hint about dependencies, not documentation.
Getting it running: the README points at CONTRIBUTING.md, not at a compose file
This is where the documentation is thinnest. The README's Developer Guide section says only: refer to the contributing guide for how to install Meteroid from sources. There is no docker compose up line, no environment variable table and no migration command in the material supplied here. The Deployment section begins with a note recommending Meteroid Cloud for testing and then states that self-hosting guidance is provided, but the excerpt cuts off immediately after that sentence.
So the honest answer to how you install it is: the source install path lives in CONTRIBUTING.md, which is not part of this material, and the self-hosting path is described after the point where the README excerpt ends. Anyone evaluating Meteroid should read those two files before anything else, because the deployment story determines whether the rest is usable. A Rust core plus a TypeScript frontend plus ClickHouse plus whatever the billing engine persists to is not a single-binary deploy, and the README does not claim otherwise.
The one concrete operational instruction the README does give is the hosted alternative: a free workspace at app.meteroid.com/registration, described as ready in seconds with no credit card. That is a legitimate way to evaluate the pricing model and the invoice output before deciding whether the self-hosted footprint is acceptable.
The experimental label and the release-candidate cadence
The repository carries a status badge reading experimental, and the most recent releases are v1.0.0-rc7 (August 2026), v1.0.0-rc6 (June 2026) and v1.0.0-rc5 (June 2026). There is no stable v1.0.0 in the release list. That combination matters more than any feature list: a billing system sits between you and your revenue, and running a release candidate in that position means you own the upgrade risk.
The cadence is also uneven. Two candidates landed two weeks apart in June, then a two-month gap to rc7. That is not a criticism of the maintainers, but it is the kind of schedule that makes pinning a version and reading the diff before upgrading the only sensible policy.
Second limitation: the README lists Insights and Reporting as coming soon. The repository description advertises revenue analytics and actionable insights, and the topics include analytics, but the feature itself is marked as not yet available. If your finance team needs month-end reporting out of the box, that requirement is currently unmet by the project's own account. The README also notes the platform is for product-led or sales-led teams, which is broad positioning; the actual constraint is narrower, and it is that you are adopting an opinionated data model for plans, metrics and subscriptions.
AGPL-3.0 and what it means for a billing service
Meteroid is licensed under AGPL-3.0, per the LICENSE file and the badge in the README. For a billing system this is a decision point, not a footnote. The AGPL's network clause is generally understood to extend copyleft obligations to users who interact with modified software over a network, which is exactly the deployment shape of a self-hosted billing API. If you fork Meteroid, modify it, and expose it to your customers, the licence question is live.
This is not legal advice and the exact scope depends on your situation. What is worth doing is a specific one: before you build on Meteroid, have someone who can read the licence compare your intended deployment against it, particularly if you plan to embed billing inside a product you distribute. The README's own framing, that the philosophy is rooted in open source and open startup culture and that transparency and collaboration are foundational, is consistent with a strong copyleft choice rather than an accident.
Where Meteroid stops and Stripe Billing starts
The topics list includes stripe, so the project clearly expects to coexist with Stripe rather than replace it outright. The meaningful comparison is not Meteroid versus a payment processor; it is Meteroid versus the combination of Stripe Billing plus a hand-rolled metering pipeline.
Stripe Billing gives you subscription objects, invoices and a mature payments surface, and it handles the money movement. What it does not give you, in the same box, is the ability to model arbitrary pricing structures and version them so existing customers are insulated from changes, or to transform raw usage events into billable metrics without pre-aggregation. That transformation layer is the part teams usually build themselves, and it is the part Meteroid claims to own. The README's phrasing, that plans are versioned so pricing changes never affect existing customers unless you want them to, is the clearest statement of where the project thinks its value sits.
The trade-off is operational. Stripe Billing is a hosted dependency you do not run. Meteroid is infrastructure you deploy, upgrade and monitor, and it is at release-candidate stage. Choosing Meteroid means accepting that responsibility in exchange for control over the pricing model and the metering path.
What to verify before you commit
Three things, in order. First, read CONTRIBUTING.md and the full Deployment section of the README, since the material available here does not contain the install commands or the self-hosting configuration. If those documents do not describe a deployment you can operate, stop there.
Second, test the metering claim against your own event shape. The README states that raw usage events become billable metrics in real time without pre-aggregation, and that the ingestion path is written in Rust for high throughput. That is a claim about behaviour under load, and the only way to evaluate it is to send your own events through the system and compare the resulting invoice line items against a known-correct calculation. Do this on the hosted workspace first, where the README says setup takes seconds, before investing in a self-hosted deployment.
Third, confirm which integrations are implemented. The README lists CRM, accounting and payments under Integrations and links to a general information page, but it does not enumerate specific connectors. If your finance stack depends on a particular accounting system, verify that connector exists before you plan around it. The same applies to Insights and Reporting, which the README marks as coming soon: if revenue reporting is a requirement rather than a nice-to-have, that feature is not currently part of the product.
Editorial conclusion
Adopt Meteroid if you are building usage-based or hybrid pricing and would rather run a Rust metering service than assemble one from a general-purpose database and a payment provider's subscription objects. Do not adopt it if you need a stable billing system today, since the newest published release is v1.0.0-rc7 and the project labels itself experimental, or if AGPL-3.0 is incompatible with how you distribute your product. Before committing, read CONTRIBUTING.md for the source install path, confirm which integrations are actually implemented rather than listed, and check whether the Insights and Reporting feature, marked coming soon in the README, is required for your finance workflow.
Community notes