Licensing
Licensing
Section titled “Licensing”Phrame licenses by credits flowing down a hierarchy — from a master authority, through regional and site servers, to the client that actually uses capacity. It works online, partially connected, or fully air-gapped, and it never over-grants: no credits, no licence.
Why it matters
Section titled “Why it matters”Broadcast customers range from a single cloud tenant to a multi-region enterprise with air-gapped sites. A licensing model has to stretch across all of that without either leaking revenue or blocking legitimate use.
- Fits any deployment. The same model scales from
MLS → Site → Client(small SaaS) toMLS → Regional → Site → Edge → Client(large enterprise), and to fully air-gapped sites via signed file bundles. - Non-permissive by design. Capacity can’t be activated without credits in place — no accidental over-use, no grace credit to reconcile later.
- Pay for what you use. Usage is metered and aggregated up the chain, from monthly granularity down to per-minute for large customers, with consumption prediction to flag replenishment before exhaustion.
- Secure end-to-end. Every node holds a unique certificate; mutual TLS is enforced on every online connection.
In one line: revenue-safe licensing that reaches from the cloud to the air-gapped edge, without getting in the customer’s way.
How it works
Section titled “How it works”Licence credits are the currency. They originate at the top and are delegated downward as signed sub-pools; usage flows back up as reports.
| Tier | Role |
|---|---|
| Master Licence Server (MLS) | Global credit authority (Phrame-owned); issues signed allocations to Tier 1; drives billing and exhaustion prediction; anchors the PKI. |
| Regional Licence Server (RLS) | Holds a delegated sub-pool per region; sub-allocates to sites; aggregates usage; caches MLS state to ride out brief outages. |
| Site / Tenant Server (SLS) | Issues individual leases to clients; enforces the non-permissive policy; supports air-gap operation via file bundles. |
| Edge / Proxy Server (ELS) | Optional micro-pool tier for very large sites or cluster isolation. |
| Licence Client (SDK) | Acquires and holds a lease from its nearest server; reports consumption back up. |
Minimum deployments: small SaaS = MLS → SLS → Client; enterprise
on-prem = MLS → RLS → SLS → Client; air-gap site = MLS → (signed file bundle) → SLS → Client.
Transport is REST or MQTT, both over mutual TLS. Air-gap sites, with no network path to a parent, receive cryptographically signed file bundles and operate fully offline.
Under the hood
Section titled “Under the hood”- Topology: a rooted tree of licence nodes; depth is deployment-specific (at least four tiers supported before clients).
- Credit model: the MLS is the sole source of truth for global inventory; each tier holds a delegated sub-pool and issues smaller pools (or leases) downward. Parents cache last-known state to continue operating within a configurable grace window during brief parent unavailability.
- High availability: MLS is geo-redundant (active/standby with automated failover, or active/active with strong consistency / CRDT sync); RLS and SLS can run as HA pairs per region/site.
- Security (PKI-first): a root CA (managed by MLS or a dedicated PKI service such as OpenBao) issues a unique certificate to every node; mutual TLS is enforced throughout; air-gap bundles are cryptographically signed.
- Granularity: monthly by default, down to per-hour or per-minute for large customers, with consumption-rate tracking for proactive replenishment alerts.
The design is captured in detail in the module’s architecture docs and a set of ADRs (communication protocol, granularity, security infrastructure, implementation language).
What you actually deploy
Section titled “What you actually deploy”The tiers above are roles, not separate products. In practice a deployment is made of a small number of pieces:
| Piece | Where it runs | What it is |
|---|---|---|
| Master licence server | Phrame-operated | The global credit authority. There is one, and it is not yours to run. |
| Licence server | Your region, site, or edge | The same component fills the regional, site and edge roles — what differs is where its credit pool comes from and who it serves. |
| Billing gateway | Phrame-operated | Links credit purchases to credit grants at the master. |
| Admin CLI | Wherever you administer from | Node management, credit allocation, and the air-gap bundle operations. |
| Client SDK | Inside the licensed application | Acquires and holds a lease and reports consumption. Not a service you run. |
| Dashboard | Alongside a licence server | Pool state, consumption, and replenishment warnings. |
One component, three tiers. Regional, site and edge servers are the same binary in different positions. That is worth knowing before planning a deployment: adding a tier is a topology decision rather than a new thing to learn, and a site server can be promoted to serve sub-sites without being replaced.
The client is a library, not a daemon. Licensed applications link it, and it holds their lease. There is no separate agent to install, monitor, or forget to start — but it does mean an application has to be built against it to be licensed at all.
Air-gapped sites need the CLI, and a person. Everything a connected site does over mutual TLS, an air-gapped one does by carrying a signed bundle in and a usage report back out. That is a procedure, with someone and a schedule attached, and it is the part of an air-gap deployment most often underestimated: the credits do not renew themselves.
