Upgrades
Admin guide
Greenlight upgrades through a customer-owned updater that lives inside the same Azure subscription as the rest of the install. The updater discovers signed GitHub release artifacts, verifies them, applies eligible releases inside the customer’s cluster, and records the result. Shift never reaches into the customer’s cluster to upgrade it.
Release model
Customer releases are GitHub release tags, not stable/beta/nightly channels.
The dashboard shows the current installed version, the newest discovered release, and whether that release is eligible for automatic rollout. Customers can pause automatic updates or hold on a specific version; separate preview/stable channels are planned for later.
The rollout shape
A Greenlight release has three artifacts that roll out independently:
- Control plane image — the Greenlight services themselves.
- Provider IaC — Bicep/Terraform updates for the cloud-provider resources.
- Universal plugin packages — the Builder plugin packages that may need regeneration after a platform release.
Most releases only touch the control plane. Releases that require infrastructure changes, plugin regeneration, downtime, or manual customer prerequisites are flagged before apply.
Apply an upgrade
- Open Admin → Upgrades. The page shows the current version and any discovered release.
- Read the release notes. The dashboard inlines the release notes for the version about to be installed. Pay attention to flagged migrations or new policy defaults.
- Click Apply. The updater drains the old control-plane pods, applies any pending database migrations, and starts the new pods. The data broker stays available throughout — running apps don’t notice.
- Verify. The post-upgrade health check runs automatically. It confirms the new version is responding, the audit log is writing, and the policy check still passes.
Total time for a control-plane-only release is typically under five minutes. Provider IaC upgrades take longer because they may apply changes to the cluster, Key Vault, or networking.
Rollback
If something goes wrong and the release manifest says rollback is safe, Rollback to previous reverts the control-plane image to the version that was running before the upgrade started.
Some releases cannot be rolled back safely, especially releases with forward-only database migrations or destructive infrastructure changes. The dashboard flags that before the upgrade starts. In those cases, recovery is a forward fix rather than an automatic rollback.
Auto-update
Auto-update applies eligible releases during a configured maintenance window. The dashboard shows the next scheduled upgrade and lets you skip or pause when policy allows it.
Automatic rollout only applies when the release declares itself safe: supported source version, no downtime requirement, no manual prerequisite, no destructive infrastructure change, and safe migrations. Anything outside those bounds requires an explicit admin action.
What gets upgraded by an agent plugin release
Agent plugin releases update the universal Skills body and the MCP client library. Customer-side Knowledge is unaffected. Marketplace-specific distribution details are still being validated with agent vendors, so the dashboard treats plugin regeneration as a release task rather than assuming a universal marketplace update path.