DocsOperationsDay-two operations

Day-two operations

Plan Lifecycle upgrades, backups, rollback decisions, recovery validation, and uninstall.

Do not assume that an upgrade supports zero downtime or that an application rollback also reverses data changes. Test each version transition before you use it in production.

Before an upgrade

Record:

  • the umbrella chart, core application, UI chart, Keycloak chart, and CLI versions
  • the deployed Helm values and deliberate overrides
  • the database, object-storage, registry, and Kubernetes versions
  • the ENCRYPTION_KEY Secret backup location
  • active Environments and long-running Agent or Site operations
  • the applicable Lifecycle changelog and chart release notes.

Back up durable state with the provider’s supported tools. Include the database, object storage used for logs or Sites, and encryption and configuration Secrets. Test that you can restore the related assets together.

Migration behavior

⚠️

Do not run an undocumented manual migration. An upgrade can change stored data, and helm rollback does not reverse those changes.

Back up stored data before the upgrade. Test the selected version transition in a representative non-production deployment.

Upgrade checkpoint

Continue only when the release information identifies:

  1. a supported component-version combination
  2. necessary configuration or data migrations
  3. a backup and restore validation point
  4. the rollout order
  5. the rollback safety boundary.

After rollout, make sure that /api/health, UI sign-in, repository webhooks, and one representative Environment operate correctly. Make sure that queued work progresses. Test each enabled Site or Agent surface. The health endpoint does not prove end-to-end operation.

Rollback and restore

helm rollback cannot restore data to its pre-upgrade state. If a release does not declare backward compatibility, restore all matched recovery assets. These assets include the application, database, configuration Secrets, and object-storage snapshot. Test the recovery in an isolated deployment.

Uninstall

Before uninstalling, select the resources to keep: Environment namespaces, durable data, object storage, registry images, kept Secrets, and DNS records. Record each approved target. Remove each approved target explicitly. Do not use a broad namespace or cluster deletion command. It can remove unintended resources.

See Compatibility and deprecation policy before you select an upgrade or rollback procedure.

Monitor LifecycleReleases