Customer Deployment Licensing

Pretorin issues a signed license for one persistent deployment identity. The v1 commercial limit is the total number of systems across all organizations in the deployment.

Behavior

License state	New system creation	Existing systems
Valid and below limit	Allowed	Available
Valid and at/above limit	Blocked	Available
Missing, not yet valid, expired, invalid, wrong deployment, or configuration error	Blocked	Read and export remain available

Archived systems count toward the license. Lowering a renewed limit below current usage never deletes data; it blocks additional system creation.

The application and license channels are independent. A platform update cannot grant or extend a license, and a license renewal cannot update the platform. Authentication, the web application, diagnostics, license installation, and existing-system reads and exports remain available for every license failure. There is no implicit post-expiry grace period.

Account alerts and notifications

License state is part of the same account-alert and notification experience as hosted Pretorin—not a separate customer-only subsystem. Organization owners and administrators see the current operational banner and receive an in-app alert. Active non-admin members do not receive proactive license banners or notifications, although they may view redacted status and the Systems meter in Settings → Plan & Usage.

Condition	Owner/admin banner and notification
Missing	Persistent License pending warning; one transition notification
Invalid, wrong deployment, or configuration error	Persistent destructive guidance; one safe transition notification
More than 30 days remaining	No global banner or milestone notification
30, 14, 7, or 1 day remaining	Progressively urgent banner; one notification at each reached milestone
Expired / 0 days	Persistent destructive guidance; one expiration notification

The local scheduler uses the ordinary Pretorin inbox, recipient resolution, notification preferences, and configured email, Slack, or Teams channels. Email is optional; in an enclave it can use customer SMTP without Pretorin network access. If a scheduler interval crosses several thresholds, only the most urgent reached milestone is sent, avoiding a catch-up burst. Repeated runs and multiple scheduler replicas deduplicate delivery. A replacement license clears the active condition and re-arms milestones for its new license ID and expiry.

Notification content is deliberately bounded to state, expiry/days, deployment and license IDs, and current/maximum systems. It never contains or decodes the signed token.

Request a license

Create or preserve the deployment identity:

pretorin deployment identity ensure \
  --context <customer-context> --namespace pretorin

Generate the non-secret request:

pretorin deployment license request \
  --context <customer-context> --namespace pretorin \
  --customer-id <contract-customer-id> \
  --customer-name "<customer-name>" \
  --max-systems <count> \
  --duration-days <days> \
  --output license-request.json

The request contains no Kubernetes credential, node identity, hardware serial, or customer workload data.

Install or renew

After comparing the license trust-bundle fingerprint with the out-of-band Pretorin record:

pretorin deployment license install \
  --context <customer-context> --namespace pretorin \
  --license-file ./license.jwt \
  --trust-bundle ./license-trust.json

The command updates a Secret and ConfigMap as projected files. Auth observes the change without a Helm upgrade or pod restart. It never prints the compact token.

Verify through the authenticated public API:

pretorin --json deployment license status

Example redacted fields include status, deployment ID, license ID, validity, days remaining, verifier key ID, systems used, and maximum systems. The signed token is never returned.

Renewal timing

Warnings begin at 30 days and repeat at the 14-, 7-, 1-, and 0-day milestones. Request renewal early enough for the customer’s change and media-transfer process, especially in disconnected environments. The signed exp boundary is authoritative; there is no implicit grace period.

Reliable UTC time synchronization is a prerequisite. A significant backward clock movement is reported in license status and metrics; it does not extend the signed validity interval.

Disaster recovery

Back up the complete pretorin-deployment-identity Secret through the approved encrypted cluster backup process. Restore it before starting auth. A newly generated ID does not match the existing license and requires reissuance.

Do not copy the identity and license into two concurrently active deployments unless the customer agreement explicitly permits that recovery arrangement.

Keyboard shortcuts