OpenMeter

OpenMeter turns a stream of usage events into something a company can charge for. It meters what customers consume, works out what they are still entitled to, and carries that through pricing, subscriptions, credits and invoices, which is the machinery teams end up writing themselves once a product stops being a flat monthly fee.

Events arrive as CloudEvents, are attributed to a customer, aggregated in real time and queried by time window or dimension. The runtime is the OpenMeter API and worker processes over Kafka, ClickHouse and PostgreSQL, with Redis optional for distributed deduplication and Svix for webhook delivery. API first and composable, it can own the whole path from raw usage to invoice or only the parts your stack is missing, working with the payment and tax providers you already use.

The capabilities divide along that same path.

• Metering: ingest, attribute and aggregate usage, then query it by window or dimension.
• Product catalog: versioned plans, features, add-ons and flat, recurring, per-unit, tiered, package or dynamic prices.
• Entitlements: calculate feature access and usage-limit balances for your application to enforce.
• Billing: rate charges, manage credit balances and subscription changes, and run the invoice lifecycle.
• Integration: a REST API with JavaScript, Python and Go SDKs, webhooks and external invoicing providers.

A Docker Compose quickstart brings up a local evaluation stack, which the project is careful to label as not a production topology, and the Helm chart is likewise for development deployments. Releases are beta and can break, though the metering engine has run in production for years.