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:
- The foundation is already ready.
- Auth migrates and rolls out.
- API migrates and rolls out; the worker uses the same API release.
- AI uses the API digest and waits for API readiness.
- 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.