Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Customer-Managed Deployment Overview

Pretorin customer deployments use stable Helm charts and immutable container digests. A new application build does not require a new chart handoff or a manual full reinstall.

The supported contract is:

ComponentSupported version
Pretorin chart contract1.0.0
Flux CLI prerequisitev2.9.4
Kubernetes1.31 through 1.36
ORAS for disconnected transfer1.3.0

The application release channel is separate from the customer license:

  • Versioned OCI charts describe stable Kubernetes resources.
  • Each application release is a signed OCI artifact containing exact API/AI, auth, and web image digests.
  • A movable stable tag is only a discovery pointer. Pretorin Pod specs never run :latest or :stable.
  • Flux verifies the artifact signature, applies its release values, runs migrations, and rolls components in auth → API → AI/web order.
  • The signed license is bound to one persistent deployment ID and controls the deployment-wide number of systems. Updating it does not update the app.

Kubernetes still replaces Pods to run new container bits. “No full redeployment” means an operator does not reinstall the platform or receive a new chart bundle for each build; Flux performs the normal controlled rollout.

Update modes

ModeBehavior
AutomaticFlux follows the verified stable release at its polling interval.
ApprovalThe release source is suspended until an operator runs pretorin deployment flux resume.
ManualAn operator verifies an immutable release and runs component Helm upgrades without Flux controllers.
Air-gappedSigned artifacts and signature referrers are transferred into an internal registry; local stable is advanced after verification.

Foundation services—PostgreSQL, Garage, and ClamAV—use a separate chart and maintenance cadence. Application releases do not silently upgrade them.

Customer entitlement model

The standard customer install bootstraps the organization on Pretorin’s Enterprise profile. It is intentionally different from the hosted commercial tiers:

  • users are unlimited;
  • all seeded framework packages are active, including Custom Frameworks;
  • AI requests and tokens are unlimited because the deployment uses the customer’s own LLM endpoint;
  • storage, exports, API rate, and audit-retention limits use the Enterprise unlimited settings; and
  • only the number of systems is metered by the signed deployment license.

The system ceiling is deployment-wide, not per organization. The Plan & Usage page uses the same Systems meter as the hosted platform and adds redacted license ID, expiry, and deployment ID fields. AI request/token counts are informational and are shown as unlimited; Pretorin does not meter the customer’s model consumption.

At the licensed ceiling, or after license expiry, existing systems remain available but new system creation is blocked. Installing a valid replacement token updates the ceiling without a Helm reconciliation or Pod restart, including in a fully disconnected enclave.

Trust boundaries

Pretorin provides two unrelated public keys:

  1. The OCI release-signing public key verifies charts and application releases.
  2. The license trust bundle verifies customer-specific license tokens.

Neither private key enters the customer environment. Obtain both public trust artifacts through the documented out-of-band handoff and compare their fingerprints before use.

Do not post registry credentials, decoded Secrets, license tokens, model API keys, or full environment dumps in tickets or chat. Status commands in this guide are intentionally redacted.