Licensing

Orvanta’s tier ladder — Trial, Solo, Teams, Business, Enterprise — is described in Editions. This page covers how a licence is actually held and enforced: the two licence modes, which capabilities each mode’s licence answers for, seats, per-tier caps, what happens as a licence approaches expiry, and where an admin finds their licence in the product.

Licence modes

Mode	Where it applies	What one licence covers
Instance	Every deployment that can run today, self-hosted or not.	The whole running instance. One licence decides the tier, seats, caps, and every feature check for every workspace on that instance.
Workspace (managed hosting)	Planned — not available yet. Implemented in the platform, but not enabled in any release.	One signed licence per workspace, bound to that workspace and that instance, plus a separate host/instance licence for instance-wide capabilities.

Instance mode is the only mode you can run today: a single process-wide licence, checked by every workspace on the instance. It’s the right shape for a self-hosted deployment, where one licence and one tenant are the same thing.

It stops being the right shape when one running instance serves many clients: every client inherits whatever tier the instance’s one licence carries, so there’s no way to sell or cap per client. Managed licence mode is the design for that — each workspace gets its own signed licence, issued and revoked independently of every other workspace on the same instance. An instance-wide host licence remains for the capabilities that genuinely belong to the instance rather than to any one tenant (see the scope split below).

Managed hosting licensing is implemented in the platform but not enabled in any release; the sections marked “planned” describe its design. The platform refuses to switch to it: a write of licence_mode = managed is rejected while the build still has open workspace-scoped reads that cannot yet resolve a single workspace’s licence. Nothing on this page marked “planned” applies to your instance today.

Instance-scoped vs. workspace-scoped features

Every capability in the edition matrix (edition-matrix.yaml) carries a scope, in addition to the minimum tier it requires:

• instance — always answered by the host/instance licence, whichever workspace (if any) the check happens in. For capabilities that belong to the instance itself, or that run with no workspace in reach at all.
• workspace — answered by the licence of the workspace the check runs in.

In instance mode (the only mode you can run today) both kinds resolve to the same one licence, so the split has no visible effect. It becomes load-bearing once managed mode ships: a workspace-scoped feature checked with no workspace in reach will fail closed — refused with a 402, never silently answered by the host licence.

Instance-scoped (the host licence answers, in every workspace): SAML and SCIM single sign-on, password-based user creation, worker group autoscaling, the Kubernetes Operator, statistics and telemetry collection, critical system alerting, instance-wide authenticated private package registry settings, GitHub App installation and webhooks, the Prometheus /metrics endpoint, and OpenTelemetry trace/metric export.

Workspace-scoped (that workspace’s own licence answers): BPMN, DMN decision models and services, the Inbox, audit logging, git-sync deployment, the four workspace-governance controls (deploy-to target, error handler, success handler, protection rules), the execution controls (concurrency limits, job priority, deleting job data after use, debounced execution, retry randomisation, approval resume forms, schedule handlers), authenticated private package registries, disabling self-approval on an approval step, the Microsoft Teams integration, the guided first-run experience, S3/cloud storage job helpers, multiple runtime versions per script, and Dart scripts.

These lists name only capabilities that are built in the 6.0 binary. The edition matrix also classifies capabilities that are not built, or only built behind an optional Cargo feature; they are left out here rather than advertised.

Seats

A licence carries per-role seat pools, independent of the account caps below:

Seat	What it’s for
developer	An account that authors scripts, flows, or other resources.
operator	An account that runs and monitors, without authoring rights.
community	An individual whose only authorship is in their own personal workspace — a separate pool so a free individual never consumes a paid developer seat.

0 on any seat pool means unlimited, the same convention used everywhere else in the licence — it is never “zero allowed.” A licence that omits the community pool is read as unlimited for it. Enterprise’s baseline caps in the edition matrix are all 0, so unlimited.

Seats bundled at each tier’s base price (a customer can buy more as add-ons):

Tier	Developer seats included	Operator seats included
Solo	1	3
Teams	3	9
Business	6	18

Enterprise has no listed bundle — it’s quoted.

Adding a seat beyond the licensed count is refused, but an instance already over its seat count is never locked out of existing users — only growing the seat count further while already over the cap is blocked. Reassigning or relicensing an existing account never trips this.

Caps per tier (instance mode)

Per-instance caps and allowances, from the edition matrix. 0 means unlimited. The platform enforces whatever the signed licence carries; these are the numbers the licence service seeds licences from, and an individual licence can differ:

Tier	Developers	Operators	Total accounts	Workspaces	Groups	Job-run retention	Hosting
Trial (unlicensed)	1	1	2	1	1	30 days	Managed only
Solo	1	10	11	1	1	30 days	Managed only
Teams	10	100	110	3	4	30 days	Managed only
Business	50	1,000	1,050	4	20	90 days	Managed or self-hosted
Enterprise	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Managed or self-hosted

An unlicensed self-hosted instance runs at Trial. Trial is entitled exactly as Solo — every feature check answers the same way — but its account caps are tighter than Solo’s (1 developer + 1 operator against Solo’s 1 + 10): unlicensed and paying-for-Solo are different commercial states, and Trial’s tighter cap exists so a self-hosted install doesn’t get Solo’s headroom for free.

Notes that apply to every row above:

• A cap only blocks creating a new resource beyond it. An instance already over a cap — for example after a downgrade — keeps every workspace, group, and account it already has; it just can’t create more until it’s back under the cap or upgrades.
• The group cap counts more than workspace groups. Since 6.0.0 it counts workspace groups (in non-archived workspaces, excluding the built-in system groups such as all) plus instance groups — the groups created by SCIM provisioning, the admin panel’s instance groups, and orvanta instance push. Earlier builds only counted workspace groups, which left SCIM and instance groups as an uncounted route to unlimited groups on any tier.
• Executions per month is not an enforced cap. The edition matrix carries a monthly execution allowance per tier (500 / 500 / 5,000 / 50,000 / unlimited, Trial through Enterprise), but nothing in the platform meters it yet — it must not be treated as a hard limit until enforcement ships.
• A few other tier-gated capabilities are licence-enforced, not just sold: authenticated private package registries (a plain, credential-free mirror or proxy URL works on every tier) require Enterprise; disabling self-approval on an approval step requires Enterprise; the Prometheus /metrics endpoint and OpenTelemetry export both require Business or above. See Upgrading to 6.0.0 for the full list of limits that only became licence-enforced in 6.0.0.

Expiry behaviour

Instance licences

An instance revalidates its licence against https://license.orvanta.cloud every 6 hours and escalates from the first failed validation — it never shuts the instance down. See Requirements: outbound access to the licence service for the full ladder (24 h in-product warning, 48 h email to every instance admin, 72 h read-only and a fall-back to Trial limits) and exactly what “read-only” does and doesn’t restrict.

Two behaviours worth knowing:

• A licence past its own signed expiry does not wait out the ladder. If validation is failing and the licence the instance is holding has already passed its signed expires_at, the instance goes read-only with Trial limits immediately.
• There is no offline mode. Every validation is a live request to the licence service, so an instance that cannot reach it is on the ladder above, not running quietly in isolation.

Two different responses, on purpose. A capability above your tier returns 402, and so does exceeding a tier cap or seat count. Read-only returns 503 with Retry-After: 21600 (6 hours, the revalidation interval), because the usual cause is the licence service being unreachable, not an unpaid invoice.

Workspace licences (managed hosting — planned, not available yet)

Managed hosting licensing is implemented in the platform but not enabled in any release. This section describes its design as merged; it can change before managed mode ships.

Each workspace’s licence runs its own copy of the same escalation shape, isolated per workspace — one workspace’s licence lapsing degrades only that workspace, never the instance or any other workspace on it.

• Where licences come from. The instance fetches each workspace’s signed licence from the licence service using the host licence key, and re-verifies it in every process before using it. A licence only applies if its signature is valid, its scope is workspace, its hosting is managed, it names this instance and this workspace, and it carries a licence id. A stored row is data, never a credential.
• Refresh. Every 15 minutes, on boot, when a workspace is created, and on demand when a superadmin calls POST /api/settings/refresh_workspace_licences. Refreshes triggered by workspace creation are single-flight and limited to one per 30 seconds.
• The ladder starts at the earliest of: the licence passing its own expires_at; the licence service no longer serving that workspace (revoked or unbound); or the held licence’s issued_at being more than 24 hours old, meaning the service has not reconfirmed it.
• From that point: 24 hours, a warning appears in that workspace’s entitlements; 48 hours, that workspace’s admins are emailed; 72 hours, the workspace — and only that workspace — becomes read-only with Trial limits. Running and scheduled jobs keep completing; read-only is an API guard, not a worker switch.
• Faster than the ladder. An expired licence grants Trial at once, and a revoked or unbound one is Trial from the moment the service stops serving it. A stale one keeps its tier through the grace period.
• Mass-revocation guard. A single refresh may not revoke more than half of an instance’s live workspace licences (from three workspaces up). If it would, the whole refresh pass is refused, so a truncated response from the licence service cannot silently downgrade every workspace. Held-back licences then age through the ladder, reaching Trial and read-only at most about 96 hours after their last refresh. If the revocation is genuine, a superadmin applies it at once with ?apply_pending_revocations=true on the refresh call, for that one refresh only.
• No licence means Trial. A workspace with no verified licence gets Trial limits. Creating a workspace requires a licence already bound to its id in the licence service; otherwise creation is refused. A workspace-scoped feature checked with no workspace in scope is refused with a 402.
• The host licence keeps degrading exactly as described for instance mode, independent of any one workspace. Managed mode also requires a live host licence with scope instance and hosting managed; if it lapses, every workspace answers as Trial and workspace creation is refused until it is renewed.

Where admins see their licence

Instance licences

Instance Settings → License key (superadmin: /#superadmin-settings) shows the configured key, lets you renew it or open the customer portal, and flags whether the instance is registered as non-prod. See Instance Settings: License key for the full field reference.

You can also supply the key as the LICENSE_KEY environment variable (not ORVANTA_LICENSE_KEY, which nothing reads). A key saved in Instance Settings takes precedence over the environment variable and applies without a restart.

Workspace licences (managed hosting — planned, not available yet)

Managed mode has no licence input: workspace licences are issued in the licence service, never typed in. The views below are planned and land with platform pull request #1956, which is not merged — do not expect them in a release yet.

• A read-only Licence tab in workspace settings, showing that workspace’s tier, state (ok, degraded, read-only, missing or retired) and expiry. In instance mode it would show the shared instance licence.
• A superadmin list of every workspace’s licence binding, with a refresh-from-licence-service button.

Seat counting per workspace is also not shipped (platform pull request #1959, open); it is one of the things keeping managed mode switched off.

Related

• Editions — the five tiers and what each one includes.
• Upgrading to 6.0.0 — the licence-enforcement changes 6.0.0 introduced.
• Requirements — outbound access to the licence service, and the full instance expiry ladder.
• Instance Settings — configuring and renewing an instance’s licence key.