Upgrade from 2026.07 to 2026.09

Follow this page from top to bottom to upgrade a Self-Managed Kindo install from 2026.07 to 2026.09. Plan a maintenance window with each organization’s IdP administrator available: SSO sign-in fails until you restore SSO for each organization after the upgrade.

Prepare

Complete these steps before the maintenance window.

1. Back up the configuration with the 2026.07 CLI. You need current copies of install-contract.yaml and environment-bindings.yaml for this install. If you don’t have them, write them from the cluster, and replace any placeholder admin database credentials in the generated environment-bindings.yaml with real ones:

   kindo config reconstruct --context <kube-context>

   From the directory holding both files, run the backup against this install’s cluster:

   kindo config backup --context <kube-context>

   The command requires openssl and prompts for a passphrase. Store the bundle and passphrase away from the cluster, and keep the 2026.07 CLI artifact. Rolling back requires both.

2. Provision what 2026.09 needs.

   Requirement	What to do
   Superadmin host	Point DNS for superadmin.<domain> at your ingress load balancer, and cover it with a TLS certificate. A wildcard record and certificate for *.<domain> already cover it.
   External Secrets Operator	The upgrade installs the External Secrets Operator, so run it as an identity that can create CRDs and admission webhooks. If the cluster already runs the External Secrets Operator, upgrade it to 0.17 or later first.
   Pod security	If you enforce Pod Security Admission baseline or restricted, allow two workloads. The per-node log collector in kindo-monitoring runs as root, mounts /var/log/pods and /var/lib/otelcol/logs from the host, and uses the system-node-critical priority class. Sandbox pods in sandbox run an init container as root that adds the NET_ADMIN, NET_RAW, CHOWN, and FOWNER capabilities.
   SMTP relay	Have an authenticated SMTP relay ready. Kindo sends sign-in codes by email.

3. Confirm you can snapshot and restore every PostgreSQL instance Kindo uses. Don’t take them yet: you take them at the start of the maintenance window, immediately before the upgrade.

4. Move model proxy clients to the API. 2026.09 no longer publishes litellm.<domain>. Point anything that calls it at https://api.<domain>/v1 with a Kindo API key, created under Settings → API in Kindo.

5. Arrange the SSO migration. List the organizations that use SSO, and book each one’s IdP administrator into the maintenance window.

Update the configuration

1. Install the 2026.09 CLI and its tools. The CLI requires kubectl 1.32 or later, Helm 4.0 or later, helmfile 1.2 or later, and yq 4 or later. The commands on this page use 2026.09.0. If a later 2026.09 release is out, use it instead. Pull, verify, and install the CLI, then check its version:

   helm registry login registry.kindo.ai --username '<registry-username>'
   helm pull oci://registry.kindo.ai/kindo-cli/kindo-cli --version 2026.09.0 --untar
   (cd kindo-cli && sha256sum -c SHA256SUMS)
   uv tool install --force ./kindo-cli/kindo_cli-*.whl
   kindo --version

2. Check SMTP. Make sure smtp.host, smtp.user, smtp.password, and smtp.fromEmail are set in install-contract.yaml. smtp.port defaults to 587. kindo upgrade stops with an error until they’re set.

3. Migrate the install contract. Preview the changes, then apply them:

   kindo config migrate --dry-run
   kindo config migrate

   Check operatorEmail in the migrated contract. The upgrade makes that address the install’s first superadmin. kindo config migrate fills it in from adminUser.email; if it’s empty or should be someone else, set it.

Upgrade

Run these steps in the maintenance window, from the directory holding install-contract.yaml and environment-bindings.yaml.

1. Snapshot every PostgreSQL instance Kindo uses. Use your managed snapshot mechanism or a consistent pg_dump. A rollback loses anything written after the snapshot, so take it immediately before the upgrade.

2. Check cluster health. Resolve every finding marked critical; the upgrade refuses to start while one remains. Findings marked warning don’t block the upgrade.

   kindo doctor

3. Preview the upgrade.

   kindo upgrade --version 2026.09.0 --plan

   If you changed Helm values directly, for example with helm upgrade --set, the upgrade resets them. The plan lists them under Helm Values. To keep one, save it as an override:

   kindo config helm-override set <release> <path>=<value>

   Fix every blocking issue the plan reports, then run the plan again.

4. Apply the upgrade.

   kindo upgrade --version 2026.09.0 --apply

   If the run fails, fix the cause and run the same command again; it is safe to repeat. If it completes with warnings, run the kindo install --step command each warning names.

5. Store the superadmin key. The upgrade prints it once. Keys expire after 90 days by default.

6. Add the superadmin routes. Create one Ingress in each backend’s namespace for superadmin.<domain>:

   Path prefix	Namespace / Service	Port	Health check
   /auth, /superadmin	api / api	80	/healthcheck
   /	superadmin / superadmin	80	/health

   Give the /auth and /superadmin routes priority over /, so those paths reach the API.

7. Sign in to the superadmin dashboard. Open https://superadmin.<domain>, enter your operatorEmail, and sign in with the emailed code.

   Until the superadmin’s organization has a SAML connection configured, the superadmin can sign in with an emailed code even if the organization enforces SSO. Once its IdP metadata is uploaded, the superadmin signs in with SSO like everyone else.

Restore SSO for each organization

Create a SAML connection for each organization that uses SSO, and update its IdP application. Members of an organization that enforces SSO can’t sign in until its connection works. Members of an organization without enforcement can use Continue with email in the meantime.

Restore SSO for your own organization last, and keep your superadmin dashboard session open until its SSO works. For each organization:

1. Open an Admin session. In the superadmin dashboard, open the organization’s Users tab, open an active Admin’s actions menu, and select Impersonate… → Prepare session. Confirm with the emailed code, then select Open customer app. Impersonation works with SSO enforcement on, and the session lasts one hour. If the organization has no eligible Admin, select Add user in the Users tab, set Organization role to Admin, and impersonate the new user.

2. Create the SAML connection. In Kindo, open Settings → SSO and select Create SAML connection. Under Identity Provider (IdP) Configuration, import the metadata from the organization’s existing Kindo application in the IdP: select Upload metadata XML and choose the file, or paste the XML and select Import. To enter the values by hand instead, fill in IdP Entity ID, Redirect URL, and Signing certificate, then select Save. The Provider notes below show where Okta and Microsoft Entra ID keep these. Confirm that the certificate shows Valid until <date>. If Kindo reports that the organization has no SSO email domain, open the organization’s Domains tab in the superadmin dashboard, select Edit domains, turn on Verified for its domain, and select Save domains.

3. Update the existing IdP application. Copy the ACS URL and SP Entity ID from Service Provider Configuration and give them to the IdP administrator. In the existing Kindo application, have them replace the ACS URL and SP Entity ID with the new values.

4. Confirm SSO and end the Admin session. In a private window, sign in with SSO as a member of the organization; for your own organization, that can be you. If sign-in fails, fix the connection in the Admin session. Once it works, return to the superadmin dashboard, open Overview → Active impersonations, and select End for the session.

Provider notes

Okta

• Create the SAML connection:
  • Option 1, upload metadata: on the Kindo application’s Sign On tab, open the Metadata URL and save the page as an .xml file.
  • Option 2, enter the values by hand: from More details on the same tab:
    • IdP Entity ID: Issuer
    • Redirect URL: Sign on URL
    • Signing certificate: the full contents of okta.cert, from Download on the Signing Certificate row
• Update the existing IdP application: open General → SAML Settings → Edit. Set Single sign-on URL, Recipient, and Destination to the ACS URL, and Audience URI (SP Entity ID) to the SP Entity ID.

Microsoft Entra ID

• Create the SAML connection:
  • Option 1, upload metadata: download Federation Metadata XML from the Kindo application’s SAML Certificates section.
  • Option 2, enter the values by hand:
    • IdP Entity ID: Microsoft Entra Identifier
    • Redirect URL: Login URL
    • Signing certificate: the full contents of the Certificate (Base64) download
• Update the existing IdP application: open Single sign-on and select Edit in Basic SAML Configuration. Set Reply URL (Assertion Consumer Service URL) to the ACS URL, and Identifier (Entity ID) to the SP Entity ID.

Finish the upgrade

1. Verify the install. Confirm that kindo status shows 2026.09 and kindo doctor reports no critical findings, then sign in to Kindo, open a chat, and run an agent:

   kindo status
   kindo doctor

2. Back up the configuration again. The upgrade generates new credentials that the pre-upgrade bundle doesn’t have. Keep the pre-upgrade bundle for rolling back to 2026.07.

   kindo config backup --context <kube-context>

3. Switch sandboxes to OpenShell.

   1. Sign in to Unleash at https://unleash.<domain> as admin. The password is unleash.adminPassword in the secrets config; read it with kindo config edit, then quit the editor without saving.
   2. Open the SANDBOX_PROVIDER flag and edit its strategy in the production environment. Give the openshell variant all of the weight and the other variants none, then save.
   3. Run an agent that executes code, and confirm it succeeds.

4. Retire the model proxy hostname. Remove the DNS record and certificate for litellm.<domain>.

5. Remove SSOReady once every organization’s SSO works:

   1. Set applications.ssoready: false in install-contract.yaml.

   2. Uninstall the release:

      helm uninstall ssoready -n ssoready

   3. Retire the sso., sso-auth., sso-api., and sso-app. DNS records and certificates.

Roll back to 2026.07

Kindo supports fixing forward: fix the cause of a failed upgrade and run kindo upgrade --apply again, which is safe to repeat.

If you can’t fix forward and need to return to 2026.07:

1. Prepare an empty cluster and reinstall the 2026.07 CLI from the artifact you kept:

   uv tool install --force <2026.07-artifact-dir>/kindo_cli-2026.7.*.whl

2. Restore the pre-upgrade database snapshots at their original hostnames. Everything written after the snapshots is lost.

3. Restore the configuration backup with the 2026.07 CLI, from an empty directory:

   kindo config extract <bundle>
   kindo restore <bundle>
   kindo status
   kindo doctor

4. Revert each IdP application. Have each IdP administrator put back the ACS URL and SP Entity ID the Kindo application used on 2026.07.