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 Greenlight resource group and cluster, and records the result. Shift never reaches into the customer’s cluster to upgrade it.
Release model
Section titled “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
Section titled “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 Greenlight 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
Section titled “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, networking, or managed-identity role assignments inside the Greenlight resource group.
Rollback
Section titled “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
Section titled “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
Section titled “What gets upgraded by an agent plugin release”Agent plugin releases update the universal Skills body, MCP configuration metadata, and agent-specific marketplace wrappers. Customer-side Knowledge is unaffected. When a release changes those generated artifacts, Greenlight regenerates the customer plugin tree and direct-commits it independently to every managed public or private marketplace repository; no pull request is opened for marketplace updates, and one failed/diverged source does not block the others.