Thyris CLS Product Licensing
Thyris CLS (Centralized License Service) provides centrally issued licenses for Thyris on-premise and customer-managed products. Each license is bound to a product and installation and defines the purchased plan, enabled features and extensions, applicable limits, validity period, and supported product version range.
The product verifies signed licensing information locally and blocks licensed functionality when a valid decision is unavailable. Editing application configuration, Helm values, a ConfigMap, or an ordinary Kubernetes Secret does not grant product entitlements.
Each license is bound to its named product as well as its installation. A valid license for one Thyris product cannot activate another product, even when both products use the same Thyris CLS signing authority.
Licensing concepts
| Concept | Meaning |
|---|---|
| Product | The licensed Thyris software, such as ACP Engine |
| Plan | The commercial entitlement set selected for the product |
| Installation | One enrolled deployment with its own stable identity |
| Feature | A licensed product capability |
| Extension | An optional module or integration |
| Limit | A maximum such as seats, workspaces, or resources |
| Meter | A measured usage category governed by the plan |
Feature and extension availability is enforced by the product APIs, not only by the user interface. A user or service also needs its normal product permissions; a product license does not replace authentication, tenant isolation, or role authorization.
Standard lifecycle
- Thyris creates the customer license for the agreed product and plan.
- The deployment creates a unique installation identity.
- Thyris issues a one-time activation key for that installation.
- An administrator activates the product through its setup screen, or an approved bootstrap Secret supplies the key once.
- The product verifies its signed license and opens only the licensed capabilities.
- Connected installations renew licensing state automatically. Offline installations use a separately approved, time-bounded signed bundle.
Activation keys are secrets. Do not send them in email/chat, store them in Git, or place them directly in Helm values. Use the product activation screen or a restricted secret-management workflow. Remove bootstrap material after it has been consumed.
Signing-key responsibilities
Thyris creates, protects, rotates, and uses the private signing keys. Customers do not receive or manage these private keys. Supported product images contain only the approved public verification set needed to validate signed licensing information.
Public verification keys and their fingerprints are not credentials, but their integrity is security-critical. Do not replace or inject a verification key through runtime configuration. Install the supported Thyris image or maintenance image published for the relevant rotation cycle.
Customer responsibilities
- keep the installation ID stable for the lifetime of the deployment;
- synchronize system time and maintain the connectivity required by the chosen license mode;
- protect Kubernetes Secrets with encryption at rest and least-privilege RBAC;
- keep product images and Helm charts on supported versions;
- follow the annual version support and key-rotation schedule;
- monitor license status and renewal/expiry warnings;
- contact Thyris before moving a license to a replacement installation or changing between connected and offline operation.
Do not copy license state, activation material, or signed bundles between installations. A restore or infrastructure migration that changes the enrolled installation should be coordinated with Thyris Support.
Support information
When reporting a licensing issue, include the product/version, installation ID, selected mode, timestamp, visible decision/error code, and request correlation ID. Never include activation keys, local service credentials, encryption keys, private keys, or full signed license bundles.