Open Source Metronome Alternatives

Flexprice is monetization infrastructure for teams whose pricing does not fit a standard subscription tool. Applications, agents or workflows send usage events, and the platform takes over the metering, credit application, entitlement checks and invoicing that otherwise turns into custom billing code nobody wants to maintain.

Processing happens in real time. Events arrive from your backend through Go, Python and JavaScript SDKs, or stream in from a data warehouse or analytics pipeline. Once billing is computed the results flow outward, syncing invoices to a payment processor, customer data to a CRM and revenue figures to accounting.

The core splits into a handful of pieces you can adopt separately.

• Usage metering: define granular events such as API calls, compute time or database queries and aggregate them as they land.
• Credit grants: prepaid and promotional credits, automatic top-ups at thresholds, and expiry for what goes unused.
• Pricing plans: seat-based, pay-as-you-go, volume-tiered and hybrid models, with per-customer overrides and plan versioning.
• Feature management: toggles, metered limits and configuration values enforced per plan or per customer.
• Subscriptions and invoicing: proration, overages and credits produce invoice lines tied back to tracked usage.

Written in Go and self-hostable, Flexprice suits teams that dislike percentage-of-revenue fees or opaque billing logic and want to read the code that charges their customers. Local development runs on Docker Compose, and it can layer over an existing provider such as Stripe or Chargebee instead of replacing it.

Autumn sits between Stripe and your application so pricing stops leaking into your codebase. Products and plans are defined on a dashboard, your app makes a few calls, and upgrades, downgrades, cancellations, failed payments and webhooks stop being yours to maintain.

The argument behind it is that billing infrastructure gets complicated faster than teams expect. Payments are the easy half; the rest is permission management, metering, usage limits driven by cron jobs, and the race conditions that appear when all of that meets a plan change. Kept outside the application, a pricing experiment no longer starts with a database migration.

Three calls carry the integration. attach handles every purchase flow, returning a Stripe Checkout URL or processing an upgrade or downgrade. check asks whether a customer has access to a feature or has usage remaining. track records a usage event when a metered feature is consumed.

Any pricing model can be assembled from those pieces, including the common ones.

• Usage and overage: real-time limits reset on a schedule you choose, and customers are charged for going over.
• Credits: monetary or arbitrary credits that many features can draw from.
• Seat-based: customers are billed for their own users, each seat carrying its own limits.
• Pay upfront: a fixed quantity of a feature is bought in advance and used over time.
• Custom plans: large accounts are handled without altering application code.

Self-hosting needs bun, one install and one command, plus your own Postgres connection string if you want it. A hosted cloud version is available.

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.