Connected Updates

Connected customers consume signed application releases from an approved OCI registry. Copying images alone does not update Kubernetes: moving the signed release channel is the publication event. Application releases leave the PostgreSQL, Garage, and ClamAV foundation on its separate maintenance cadence.

Approval mode

New connected installations start with the release Kustomization suspended. Flux may discover and verify the stable candidate while the workloads keep running. Record the exact candidate sha256: digest, signer, compatible schema heads, current release, backup status, and change approval before applying it.

Use the current customer bundle’s digest-pinned approval helper from an operator workstation with access to the target cluster. It checks that the candidate is ready and signature-verified, pins the reviewed digest, waits for verified source readback, then resumes and observes reconciliation.

pretorin --json deployment flux status

APPROVED_DIGEST=sha256:REPLACE_WITH_REVIEWED_64_HEX \
APPROVER=reviewer@example.com \
APPROVAL_RECORD=CHANGE-REFERENCE-REPLACE \
KUBE_CONTEXT=customer-cluster-context \
EXPECTED_RELEASE_REPOSITORY_URL=oci://registry.example.com/pretorin/releases/pretorin \
  scripts/customer/approve-customer-release.sh

Run the helper once for each separately approved release. The CLI’s older pretorin deployment flux resume command does not accept a digest and now refuses to resume the channel. Do not patch the Kustomization directly or resume a mutable stable pointer.

Monitor the result without reading credentials or customer data:

pretorin --json deployment flux status
kubectl --context customer-cluster-context --namespace flux-system \
  get ocirepositories,kustomizations
kubectl --context customer-cluster-context --namespace pretorin \
  get helmreleases,pods,jobs

Confirm the applied digest and all four application components match the approved release, then verify externally observed health and target-owned configuration. If approval stops before application, keep the Kustomization suspended and retain the failed change record. A database migration is not undone by moving an image or Helm revision backward.

Automatic mode

Automatic following polls stable, verifies the signature, and applies a new release without a per-release operator command. It is an activation-gated option, not the new-customer default. Enable it only after customer-specific backup and restore, schema compatibility, approval-mode rehearsal, alerting, and failure-drill gates pass. Record that decision in the customer’s operations handoff.

Reconciliation order

The signed release pins image and chart digests. Flux coordinates Auth, then API and its worker, then AI and Web. The AI image uses the same API digest. Migration failure blocks later components; the controller retries or waits for operator action instead of assuming the old runtime can use the new schema.

Manual exact-digest path

When Flux controllers cannot run, use the customer bundle’s consume-platform-release-helm.sh helper. It consumes the same signed release and four customer-owned values files. Its default plan verifies release and chart signatures, complete image closures, rendered values, cluster identity, and current schema expectations without a Helm mutation. Review and retain the resulting plan hash, then repeat the identical command with --apply and --approve-plan-sha256. The foundation release is installed and maintained separately.

scripts/customer/consume-platform-release-helm.sh \
  --release-repository registry.example.com/pretorin/releases/pretorin \
  --release-digest "${RELEASE_DIGEST}" \
  --release-public-key /secure/trust/pretorin-release.pub \
  --expected-registry-authority registry.example.com \
  --context customer-cluster-context \
  --namespace pretorin \
  --foundation-namespace pretorin \
  --auth-values /secure/config/auth-values.yaml \
  --api-values /secure/config/api-values.yaml \
  --ai-values /secure/config/ai-values.yaml \
  --web-values /secure/config/web-values.yaml \
  --initial-install \
  --plan-output /secure/change/release-plan.json

PLAN_SHA256="$(jq -er '.planSha256' /secure/change/release-plan.json)"
# Repeat the exact command above, adding:
#   --apply --approve-plan-sha256 "${PLAN_SHA256}"

For an update, replace --initial-install with the reviewed current platform version plus both current API and Auth Alembic heads: --expected-current-release-version, --expected-current-api-schema-head, and --expected-current-auth-schema-head. Use the full bundled manual-helm-release.md procedure in the customer bundle for tool pins, plan review, ordered apply, and compatible rollback. Hand-written helm upgrade commands cannot enforce the same signed release and cluster binding.

License lifecycle

The deployment-bound license is independent of application releases. A connected install may start while issuance is pending: leave the token absent until the signed file arrives. Auth and Web become ready, the owner can log in and see License pending, and new system creation waits. Install or renew the token with pretorin deployment license install; no Flux or Helm reconciliation or Auth restart is required. See Licensing and Operations.

Roll forward and compatible rollback

If a release fails after migration, preserve the evidence and prefer a corrected signed release. Runtime rollback is permitted only when signed compatibility metadata proves the predecessor can use the current schema. Review and pin the older immutable digest through the same approval process. Database and object store recovery require the customer’s separate restore procedure.

Keyboard shortcuts