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

Connected Updates

Connected customers consume a signed release from their own registry. Uploading container images alone does not update Kubernetes; promotion of the signed release artifact is the commit event.

Automatic mode

Flux polls the stable tag, resolves it to an immutable digest, verifies its Cosign signature, and applies the release. No operator command is required.

Monitor without exposing credentials:

pretorin --json deployment flux status
kubectl --namespace flux-system get ocirepository pretorin-release
kubectl --namespace flux-system get kustomizations \
  pretorin-release pretorin-release-auth pretorin-release-api \
  pretorin-release-ai pretorin-release-web
kubectl --namespace pretorin get helmreleases

A healthy result has a release artifact digest, release.source_ready=true, release.apply_ready=true, and all four application components ready at the same release ID.

Approval mode

Approval mode keeps signature-verified candidate discovery active but suspends the Kustomization that applies it. Existing workloads keep running while an operator verifies the candidate digest through the approved change process.

pretorin --json deployment flux status
pretorin deployment flux resume --context <customer-cluster-context>

resume both clears the apply suspension and requests immediate reconciliation. To keep discovering—but not applying—later releases after the approved update finishes:

pretorin deployment flux suspend --context <customer-cluster-context>

Suspending Flux does not stop running workloads, stop signed candidate discovery, or roll anything back.

License lifecycle is independent

A connected installation may start while its deployment-bound token is still being issued. Leave the license input absent—never use a placeholder. Auth and the UI remain ready, the bootstrap owner can log in and see License pending, and only new system creation is denied. Install the signed token later with pretorin deployment license install; the banner clears without Flux or Helm reconciliation and without an Auth Pod restart.

Owners and administrators receive local notifications at 30, 14, 7, 1, and 0 days through the existing preferences and delivery channels. Expiry preserves login, diagnostics, existing-system reads, and exports. Enable and route the customer Prometheus rules as described in Operations. These checks do not depend on the connected release channel and never send license material to Pretorin.

Reconciliation order

The channel source is discovery-only. After approval, the signed release creates a second signature-verified source pinned to the immutable release version. Component Kustomizations consume that pinned source and coordinate the HelmReleases. Flux enforces this sequence:

  1. The foundation is already ready.
  2. Auth migrates and rolls out.
  3. API migrates and rolls out; the worker uses the same API release.
  4. AI uses the API digest and waits for API readiness.
  5. Web waits for the matching API and auth release.

Migration failures block the new runtime. The release uses retry-on-failure; it does not automatically put an old binary back on a newly migrated schema. The pinned applied source also prevents a later movement of stable from bypassing the approval Kustomization.

Manual exact-digest path

Use this only when Flux controllers are prohibited. Keep the Flux CLI locally for OCI artifact handling; it does not install controllers by itself.

export VERSION=<approved-release-version>
export RELEASE_REPOSITORY=<registry.example.com/pretorin/releases/pretorin>

cosign verify --key ./pretorin-release.pub \
  "${RELEASE_REPOSITORY}:${VERSION}"
flux pull artifact "oci://${RELEASE_REPOSITORY}:${VERSION}" \
  --output ./pretorin-release
jq . ./pretorin-release/platform-release.json

Apply customer values first and signed release values last. Upgrade all four services, not a single component. The database foundation is separate. Extract the four values payloads with yq:

yq -r 'select(.kind == "ConfigMap" and .metadata.name == "pretorin-auth-release-values").data["values.yaml"]' \
  ./pretorin-release/release-resources.yaml > auth-release-values.yaml
yq -r 'select(.kind == "ConfigMap" and .metadata.name == "pretorin-api-release-values").data["values.yaml"]' \
  ./pretorin-release/release-resources.yaml > api-release-values.yaml
yq -r 'select(.kind == "ConfigMap" and .metadata.name == "pretorin-ai-release-values").data["values.yaml"]' \
  ./pretorin-release/release-resources.yaml > ai-release-values.yaml
yq -r 'select(.kind == "ConfigMap" and .metadata.name == "pretorin-web-release-values").data["values.yaml"]' \
  ./pretorin-release/release-resources.yaml > web-release-values.yaml

helm upgrade --install pretorin-auth \
  oci://<registry.example.com/pretorin/charts>/pretorin-auth \
  --version 1.0.0 --namespace pretorin \
  -f auth-customer-values.yaml \
  -f auth-release-values.yaml --wait --timeout 30m

helm upgrade --install pretorin-api \
  oci://<registry.example.com/pretorin/charts>/pretorin-api \
  --version 1.0.0 --namespace pretorin \
  -f api-customer-values.yaml -f api-release-values.yaml --wait --timeout 30m
helm upgrade --install pretorin-ai \
  oci://<registry.example.com/pretorin/charts>/pretorin-ai \
  --version 1.0.0 --namespace pretorin \
  -f ai-customer-values.yaml -f ai-release-values.yaml --wait --timeout 30m
helm upgrade --install pretorin-web \
  oci://<registry.example.com/pretorin/charts>/pretorin-web \
  --version 1.0.0 --namespace pretorin \
  -f web-customer-values.yaml -f web-release-values.yaml --wait --timeout 30m

Inspect every extracted values file before the upgrade. Prefer the Flux path unless the operating procedure already controls this parsing and ordering.

Roll forward and rollback

If a release fails after a migration, correct the cause and promote a newer compatible release. Do not assume application rollback is database rollback.

A rollback is permitted only when Pretorin release notes explicitly declare the older runtime compatible with the current schema. Pin the older immutable release digest, verify its signature, and reconcile it through the same change process. Never move a Pod to a guessed tag.