Skip to main content
The platform exposes a fixed set of feature toggles. Each toggle controls one capability — a sidebar entry, an authentication mechanism, an integration surface. Operators set the toggle in the deployment’s license; the dashboard and the runtime API respect it. This page is the operator-side reference. The user-side equivalent (“which sidebar entry is missing and why”) lives at Cloud → Feature availability.

​
How features are evaluated

Two values matter for every operation:
  1. License entitlement — every feature has a key that the license either grants (true) or doesn’t. Unlisted keys are treated as false (deny by default).
  2. Operation-to-feature mapping — each operation declares the feature key it requires. Operations marked core are always allowed.
When a request arrives, the platform checks the operation’s feature requirement against the license. Denied requests return 403 with a payload identifying the missing feature; the dashboard hides the corresponding sidebar entry rather than rendering an empty shell.

​
Key namespaces

Feature and quota keys live in three namespaces. The same short key name (for example max_agents) can appear in more than one namespace, so always read a key together with its namespace.

​
Global features

Deployment-wide capabilities, sourced from the signed license. The five identity / self-service features (registration, oauth, email, oidc_provider, auto_team) are the management features — typically OFF in enterprise self-host templates, because the operator provisions users out-of-band instead of through self-service flows. mcp_server and notifications stay ON. SaaS deployments turn everything on.

​
Account features

Per-user capabilities, sourced from the license account block.

​
Team features

Per-team capabilities, sourced from the license team block.

​
Quotas

The license also carries numeric quotas. -1 means unlimited, 0 means disabled (no further requests of that kind succeed), >0 is a hard cap. Each quota lives in a namespace, exactly like a feature.

​
License templates

Cyberun ships two recommended template profiles. Operators rarely build a license from scratch; the templates are the starting point and individual keys can be overridden per deployment.
  • SaaS — every feature on, generous quotas. The shape Cyberun’s own managed service uses.
  • Enterprise self-host — the Global management features (registration, oauth, email, oidc_provider, auto_team) off, every other feature on, capacity quotas applied. The shape most on-prem deployments take.
License generation, signing, and renewal are partner-channel workflows today; reach out to get a license issued for a planned deployment. Full self-service license tooling is in development.

​
What happens when a feature expires

License validity is checked on a schedule. A request for a feature that’s simply turned off returns 403 (above); but if the whole license expires or is revoked, gated operations return 503 (service unavailable) instead. core operations (sign-in, list teams, basic read paths) continue to work so administrators can renew without locking themselves out. Plan license renewal ahead of expiry. The platform does not have a built-in grace period beyond the validity window — when the expiry timestamp passes, gated features stop.

​
See also