Flexprice sits between product usage and the money systems
Flexprice accepts usage events from an application or data pipeline, associates them with customers and features, then applies plans, meters, credits, and entitlements. It can produce invoices and send billing information toward payment, CRM, CPQ, and accounting tools. This is more than a counter in front of Stripe: it becomes the place where product activity turns into an amount owed and where paid access can be allowed or denied.
That position makes flexibility useful and mistakes expensive. The data model covers usage-based, seat-based, prepaid, promotional, tiered, and hybrid prices. Customers can have plan overrides and credit wallets. Our checkout contained 2,258 files and about 675,282 source lines in 45.3 MB. A codebase of that size can encode many pricing cases, while adopters still need to prove their own rounding, time-zone, retry, and adjustment rules.
The development stack includes five infrastructure services
The documented quick setup runs make dev-setup, which starts PostgreSQL, Kafka, ClickHouse, Redis, and Temporal before starting the API, consumer, and worker. It also runs database migrations and initializes Kafka. PostgreSQL holds transactional application data, Kafka carries events, ClickHouse supports usage storage and aggregation, Redis supports runtime coordination, and Temporal runs workflows. Docker Compose makes these pieces start together without making them one failure domain.
Running the Go server outside containers still requires those services. Optional invoice storage adds an S3 bucket, access credentials, region settings, and presigned-download behavior. Our dependency installation added 443 Go packages in 79 seconds, a reasonable download for a large service, but the local source build does not represent the storage, queue, and workflow capacity needed for real customer events.
What happened when we ran it
Our fresh Debian sandbox cloned commit e4b5303 with 3 CPUs and 8 GB of RAM. Go installed 443 packages in 79 seconds. The build completed successfully in 233 seconds. The repository included 10 CI workflow files, a Dockerfile, and Compose configuration. It had no top-level tests directory, though the Go packages contained tests discoverable by the command.
The test step ran for 266 seconds and exited with code 1. The harness counted 46 passing and 2 failing packages out of 48. The supplied tail listed successful validator and webhook packages, several packages with no test files, and a final FAIL; it did not include the names or messages for the two failures. We cannot judge their billing impact from that tail, so the next evaluation step is to reproduce the complete output.
Billing needs replay and reconciliation before cutover
A passing build shows that the code compiles. It does not prove that an event retry cannot be billed twice, a late event lands in the correct period, a plan change uses the intended boundary, or credits expire in the right order. Create a corpus of invoices from the system you already trust, replay the exact source events through Flexprice, and compare line items, totals, balances, and entitlements.
Our 46-of-48 package result is close enough to justify investigation and too weak for blind adoption. Keep the trial in shadow mode, where Flexprice calculates without charging customers or enforcing access. Include duplicate identifiers, out-of-order events, cancellations, backdated changes, rounding at currency precision, and month boundaries. A billing discrepancy needs the original event, pricing version, calculation trace, and correction path, not only a dashboard total.
Kafka and Temporal add known operational edges
Open issue 2400 reports Kafka 4.x rejecting the offset-commit version used by the current Sarama client path. Issue 2399 reports a Temporal client exiting during transient frontend unhealthiness at startup. Issue 2398 describes ClickHouse producing excessive one-row parts for singleton event deliveries. These reports concern different parts of the stack, but each can affect ingestion availability or storage behavior.
Pin compatible service versions rather than following floating tags. Issue 2530 specifically asks the migration hook to stop using soldevelo/kafka:latest, which is a concrete warning against an unbounded infrastructure dependency. Release v2.1.26 added configurable Kafka topics and per-topic settings to the Helm chart, plus migration verification changes. Treat the chart as code, review every image tag, and test restart ordering with queues already containing events.
Security work reaches invoices, tenants, and webhooks
Usage events and invoices carry customer identifiers, product behavior, and financial data. Tenant boundaries must hold across ingestion, aggregation, queries, exports, and retries. Open issue 2489 asks for tenant and environment values in a unique-count hash as defense in depth. Issue 2490 asks for rate limiting on a webhook retry endpoint after a security assessment. Neither report alone establishes a working exploit, but both name boundaries worth testing.
The repository uses an open-core license: the README says the core is AGPLv3, while ee and internal/ee use a commercial license. Review both code paths and deployment terms before adopting features. The 675,282-line checkout is large enough that license inventory and security review should follow directories and build artifacts, rather than relying on a percentage claim in marketing copy.
Active releases make defects easier to discuss, not harmless
GitHub reported 4,448 stars, 212 combined issues and pull requests, and a push on August 26, 2026. Release v2.1.26 landed August 24 with usage-record search, Kafka chart settings, plan-change behavior, observability, migration checks, and integration work. The short gap between release and last push shows active development; the combined open count includes pull requests and should not be read as a bug total.
Flexprice is worth a controlled proof when usage billing has become its own engineering system. Our 233-second successful build shows the source is workable, while 2 failing packages and 5 infrastructure services make a direct cutover hard to defend. Reproduce the failures, pin every dependency, shadow existing invoices, and test recovery from queue and workflow interruptions before Flexprice can influence money or customer access.