How Limitr works
Commit your pricing policy.Ship it like code.
Limitr evaluates one policy document — real logic, not split across two vendors or bolted on after the fact — self-hosted for free or fully managed in Limitr Cloud.
Where you plug in
It runs inside your app. Your billing tool doesn't change.
Limitr runs in-process inside your app, sitting between your product's features and your billing tool — enforcing what each customer's plan allows and what it costs, then handing the result downstream. Your existing biller still moves the money.
Your Product
Where usage happens
Limitr
Prices, gates, governs, and bills every action in real time.
Your Billing Tool
Stripe, Maxio, Chargebee — or your own
Under the hood
A pricing engine, not a pricing API.
Your policy isn't static config — it's live rules and functions, evaluated inside a sandboxed WebAssembly runtime embedded directly in your process. Same runtime binary everywhere, so a decision means the same thing in every service that makes one.
Policy enforcement — pricing & access decisions, evaluated locally, in-process.
The managed layer on top — for when you're ready to stop self-hosting the control plane.
Engine advantages
No separate service
- A library in your own process, not a new service
- Nothing to deploy, version, or fail over
In your code
One document. A few lines to read it.
The policy below defines a real plan — credits, prices, limits. The snippet beside it is the whole integration: create the customer, then ask the policy if an action is allowed.
{
"policy": {
"credits": {
"seat": { "price": { "amount": 19.9924.99 } },
"token": { "price": { "amount": 0.00004 }, "overhead": 0.000003 }
},
"plans": {
"starter": {
"label": "Starter Plan",
"entitlements": {
"seats": {
"limit": { "credit": "seat", "value": 3 }
},
"ai-chat": {
"limit": { "credit": "token", "value": 1000, "mode": "soft", "resets": true, "reset_inc": "1hr" }
}
}
}
}
}
}Committed instantly — every connected service reads this next call.
import { Limitr } from '@formata/limitr';
// `policyJson` is the document shown to the left.
const policy = await Limitr.new(policyJson, 'json');
// For Limitr Cloud instead: await Limitr.cloud({ token: apiKey })
// — nothing below changes.
// A customer object holds state: meter values, overrides, plan ref.
await policy.createCustomer('acme_corp', 'starter');
if (await policy.allow('acme_corp', 'seats', 2)) {
console.log('2 seats — allowed');
}
if (await policy.allow('acme_corp', 'ai-chat', 10000)) {
console.log('10,000 tokens — allowed, charged for 9k in overage');
}Try it now
No login. No purchase. Just a policy document.
The engine is open-source. Write your first policy and watch it get enforced — right now, before you talk to us about anything.
Run it in your browser
See the engine evaluate a real policy live, running as WebAssembly, right on this page — nothing to install.
Open the demoInstall the engine
JS/TS bindings today, with more on the way — the engine itself runs anywhere WebAssembly does. Write a policy, make your first call, in about five minutes.
npm i @formata/limitrThis is the real runtime, not a limited demo — the same sandboxed environment your own services would run. Limitr Cloud is the optional managed layer on top — a hosted policy editor, sync across every connected service, team collaboration, and billing — for when you're ready to stop self-hosting the control plane.
Common engine questions
Engine & architecture
It works offline in the literal sense — the runtime evaluates your policy locally and doesn't need to reach Limitr's servers to make a pricing or access decision. There's no fallback mode to configure; that's just how a call is evaluated, connected or not.
Usage is still recorded locally either way, and syncs back to Limitr Cloud in the background once connectivity is available — nothing is lost, it just isn't blocking.
The engine — the same Rust/WebAssembly runtime that enforces your policy — is open-source and free to self-host. You write and manage your own policy document, and it runs entirely in your own infrastructure.
Limitr Cloud is the managed layer on top: a hosted policy editor with versioning and live-editing, sync across every connected service, team collaboration and audit history, and the billing/invoicing pipeline. You can start with the engine alone and add Cloud later without changing how your code integrates.
A credit defines a price — what a unit costs, independent of any plan. An entitlement lives inside a plan and references a credit to say how much of it that plan includes and how it's enforced (limit, mode, reset).
Splitting them apart means changing a price once updates every plan that references it, instead of hunting down the same number across five plan definitions.
Yes — a policy isn't limited to the primitives Limitr ships out of the box. It's built to be extended and overridden for whatever your specific product needs, which is the point of it being a real engine rather than a fixed set of billing rules.
Stof is the engine's native format — JSON and YAML are also fully supported, including everything shown above. You don't need it for a policy like the Starter plan example.
Where Stof earns its place is logic: real functions inside the document itself, for pricing or limits that can't be expressed as static numbers — a custom formula, a conditional discount, a computed tier. Start in JSON; reach for Stof only when a plan actually needs to compute something.
JS/TS today — the examples throughout the docs use it. The engine itself compiles to WebAssembly and runs anywhere Wasm does, so more language bindings are on the way; JS/TS is the place to start right now.