What Is Kaiten?

Kaiten is an open-source control plane for B2B SaaS. It unifies feature flags, entitlements, monetization, and deployments into a single data model — so that what you sell, what your customers can access, and what runs for them are one source of truth instead of three disconnected systems.

If you have ever written a script to keep Stripe, your feature-flag tool, and your CRM in sync, Kaiten is the system that replaces that script.

The one-sentence version

Kaiten turns your commercial contract into the source of truth for your infrastructure.

When a customer buys a License, that single fact should determine which features they see, which quotas they get, where their instance runs, and how they are billed. Today, those decisions are scattered across separate tools that do not share a primary key. Kaiten puts them in one model.

In practice, a feature flag's targeting rule reads the customer's contract directly:

// Flag rule (CEL) — gating by License, no glue code, no sync job
__kaiten.license.familySlug == 'premium'
  && __kaiten.entitlements['monthly-orders'].remaining > 0

Change the entitlement and the flag follows, with no deploy and no webhook chain. That is what sharing primary keys means.

How it fits in your stack

Kaiten sits on top of the tools you already use and owns the layer between them — the layer that is usually fragile glue code.

✕

✕

What you get today

The core that ships in the Community Edition:

• A feature-flag engine — OpenFeature-compatible, CEL targeting, and flags that read entitlements directly, so gating a feature by License needs no separate logic.
• Entitlements — typed access rights and quotas (booleans, numbers, AI credits, config values), enforced per License: a hard cap, a bounded overage allowance, or unlimited — with a warning threshold that fires before the cap.
• AI credits — an entitlement type of its own, NUMBER_AI_CREDIT, granted per License and metered like any number. The AI Control Plane Coming soon builds on it: your models, and the rules that convert a request into credits.
• Monetization primitives — Licenses, each one version of a product in a License family, granting entitlements to the Instances attached to it. Composable prices (a base fee plus usage meters), add-ons, and vouchers that act on a price, a quota, and a feature flag in a single redemption are on the roadmap Coming soon.
• BYO-ID — a Customer carries your own identifier (your internal customer ID, a CRM record ID), and Instances carry the metadata fields you declare, so integration starts without a reconciliation script.
• An immutable audit trail — every change and every evaluation, recorded. "Who had access to what, when?" is one query.
• A console and a CLI — operable by your team from the browser or the terminal, on the same API your product calls.

Where it's going

The commercial layer on top of Licenses comes first: native billing through the billing engine you already use, add-ons, vouchers, AI credits and threshold behaviors — with an MCP server, React components, and your own identifiers on every object. Planned after it: Kaiten Edge for air-gapped and self-hosted environments, the feature lifecycle and feature tracking, cohorts, roles, code generation, a HubSpot connector, and Marketplace deployment.

What's Coming lists each item and its status; the public roadmap takes votes.

The data model in one glance

Everything in Kaiten hangs off a single hierarchy:

Organization → Customer → Instance → License → Entitlement

Your company is the Organization. The companies you sell to are Customers. Each Customer runs one or more Instances. Each Instance carries a License (what the Customer bought), and each License grants Entitlements (what they can do). Feature flags and usage reference these same entities — which is why a change in one place is reflected everywhere, instantly.

Open-source, with a managed option

Kaiten's core is open source, under the Apache License 2.0. You can self-host the complete data model, API, flag engine, metering, and console.

Most teams start on the Community Edition to try it, then move to Kaiten Cloud when the operational burden of self-hosting outweighs the benefit — or stay self-hosted forever in regulated environments.

Who Kaiten is for

Kaiten works from your first customer. As with a CRM, the practice that works best is to adopt it early: model your licensing cleanly from day one, and the layer grows with you instead of being retrofitted under pressure later. Custom Licenses, negotiated entitlements, and instances spread across regions and deployment zones eventually break the glue-code approach as you scale, and the teams who suffer least are the ones who never let the glue code accumulate.

It is especially useful for:

• AI-native products, where per-token costs break traditional pricing and the AI Control Plane Coming soon will provide a credit abstraction customers understand.
• Teams selling to regulated industries (banking, defense, healthcare), where Kaiten Edge Coming soon will serve flags and entitlements in air-gapped environments.
• Engineering teams tired of maintaining a homegrown licensing-service stitched between billing, flags, and the CRM.

When Kaiten is not the right fit

Two cases where Kaiten is a poor fit:

• One flat License, no tiers — if every customer gets everything, there's nothing to entitle. Kaiten would add overhead without benefit.
• Pure B2C — the Customer → Instance → License hierarchy is built for selling to businesses. A consumer app with millions of individual users is a different shape of problem.

To decide, the Quickstart takes about ten minutes; trying it on one real use case is the fastest way to know.

Next steps