Why we built Meterbox in-cluster

Most usage-based billing products are SaaS: you call their API on every metered event, wait for a response, and hope their uptime is better than yours. That model works fine for low-stakes analytics. It's the wrong model for billing, where a dropped request means either lost revenue or a customer wrongly blocked from your product.

Meterbox runs in-cluster instead — alongside your application, in your own environment, with metering in the request path rather than behind it. A few consequences fall out of that one decision:

No network hop on the hot path. Every metering call is a local call. There's no external dependency between "a customer used your product" and "that usage got recorded."

No managed datastore requirement. Postgres, Redis, and backups run in the same cluster as the application. Your usage data never has to leave infrastructure you control to get billed correctly.

Configuration over code. Pricing changes — a new plan, a new tier, a new metered dimension — go through configuration, not a deployment. Engineering ships the metering hooks once; finance iterates on pricing without waiting on a release cycle.

This is also why self-hosting isn't an afterthought for us. The Self-Managed tier is the same APIs, the same code, deployed into your own cloud — because "in-cluster" only means something if it's actually true regardless of who operates the cluster.

If you want the deeper thesis behind this, Our Strategy goes further into the principles that guide what we build.