License

Scope: cluster · Singleton (must be named cluster)

Holds and validates the signed offline license, and exposes the enabled feature set and instance caps to every other controller. Licenses are claimed — downloaded, purchased, or started as a trial — from the Navique customer portal at portal.navique.dev. For the licensing model, see Editions & Licensing and Managing a License.

Spec

Field	Type	Description
secretRef	SecretKeyRef (required)	Secret holding the signed license token. Default key license.

apiVersion: core.navique.com/v1alpha1
kind: License
metadata:
  name: cluster                      # singleton — other names are rejected
spec:
  secretRef:
    name: navique-license
    key: license
    namespace: navique-system

Status

Field	Description
valid	Whether the token verified and is unexpired
licensee	Licensed entity name
tier	Convenience label (enterprise / basic / …); not used for enforcement
expiresAt	Expiry timestamp
environment	prod / nonprod
enabledFeatures	Explicit feature flags, e.g. ["auto-wiring","guardrail"]
limits	Enforced per-type caps, e.g. {"gateways":3,"langfuse":1}
includedSupportHours	Reference only; tracked off-cluster
reason	Why the license is invalid, if applicable
revoked	true if the token was rejected by the operator's built-in revocation list
revokedReason	Revocation category when revoked is true: compromised / superseded / non-compliance / issued-in-error / unspecified
conditions	Includes Ready (reason LicenseRevoked when revoked)

How verification works

The license is a signed JWT verified against a public key compiled into the operator binary (recommended algorithm: EdDSA / Ed25519; alg: none is rejected). The operator selects the verification key by the token's kid (key id) header, so the signing key can be rotated without breaking already-issued licenses. There is no license server and no phone-home, so it works air-gapped. The controller:

1. Reads the token from the referenced Secret and verifies the signature and expiry.
2. Checks the token against the operator's built-in revocation list (see Revocation).
3. Writes status (validity, licensee, tier, expiry, features, limits, environment, reason, revoked) and a Ready condition.
4. Publishes the entitlements to a concurrency-safe evaluator that every workload controller reads.
5. Requeues near expiry so gating flips on time.

The controller watches the referenced Secret, so activating a new license by overwriting the token in place (the same secretRef — how the management console activates one) is picked up immediately; you do not need to edit or re-apply the License CR. Every license-gated controller in turn watches the License, so an upgrade or downgrade re-evaluates existing instances promptly — a component that was refused under the old entitlements recovers as soon as the new license is verified.

Revocation

A license can be revoked before it expires — for example if its token leaks or was issued in error. The operator ships a revocation list compiled into the binary, so this works fully air-gapped with no online check. A revoked license is rejected even though its signature is valid, and the operator falls back to Community defaults — exactly like an expired license, so the base platform keeps running.

When a license is revoked, status.revoked is true, status.revokedReason carries the category (e.g. compromised), and the Ready condition reports LicenseRevoked. Because the revocation list is part of the operator binary, you pick up revocations (and the security fixes that ship alongside them) by keeping the operator up to date. Contact Navique if a license of yours is shown as revoked unexpectedly.

Explicit entitlements — no wildcard

The license carries an enumerated features list and quantitative limits. There is deliberately no wildcard (["*"]) entitlement — every feature and instance count is a pricing lever and is individually enforced.

{
  "licensee": "ACME Bank AG",
  "issuer": "Navique",
  "tier": "enterprise",
  "features": ["auto-wiring", "guardrail", "multi-tenancy", "sso-scim", "audit-logging"],
  "limits": { "gateways": 3, "langfuse": 1, "chatui": 2, "teams": 10 },
  "environment": "prod",
  "includedSupportHours": 40,
  "issued_at": "2026-06-01T00:00:00Z",
  "expiration_date": "2027-06-01T00:00:00Z"
}

Community defaults (no / expired license)

When there is no valid license — never issued, or expired — the operator applies built-in Community defaults and the platform keeps running:

• Paid features off (the guardrail gate fails closed).
• Instance caps drop to the free level (one of each type).
• The base platform is unaffected.

This is a graceful downgrade, not an outage. See Editions & Licensing.

What it gates

• Feature flags — e.g. auto-wiring, guardrail, multi-tenancy, sso-scim, audit-logging, and the management-plane-* family consumed by the console.
• Per-type instance caps — creating instance N+1 beyond the licensed limit is refused with a LicenseLimitExceeded condition (it is not treated as an error; the existing instances keep running).

The core platform never blocks on the license — only the paid increments are gated, always with a manual fallback or a clear renewal path.