Upgrades
Admin guide
Greenlight keeps itself current. Updates apply automatically inside your own cloud during the maintenance window you choose — including the ones that change infrastructure — and Shift never reaches into your cloud to do it. The work is done by a component running inside your own cluster, under an identity you own that cannot act outside the boundary Greenlight was installed into.
Delete protection is built into the infrastructure templates themselves: your databases, storage, DNS, and the cluster cannot be destroyed or replaced by an automatic update, whatever a release contains. A release that changes no infrastructure simply updates the application.
What you can see
Section titled “What you can see”Internal Health’s Updater panel opens on one line: whether you are current or a newer release is waiting, and when the next run is due. An Update settings and last run toggle underneath holds the rest — whether automatic updates are on, the schedule and time zone they run in, your prerelease posture, the updater’s own image, and the last check and apply. It also names whether the installer or the updater put the running release in place, so a version that changed because someone reran the installer by hand is not a mystery. Anything the install could not report says so, and says why, rather than showing a blank. The installed version itself is stated once, on Internal Health’s Versions card.
Below that is every retained run, newest first. Open one and you get the whole story: each phase with how long it took and why it ended, the exact non-secret inputs the run replayed, the release versions it moved between, and the full log the run produced — the infrastructure plan, the application rollout, and the installer’s own output — readable and downloadable long after the run’s pod is gone. Runs are kept for 90 days and their logs for the newest 30 runs.
A run that applied its release but failed one of the installer’s closing checks is labelled as exactly that, never as a failed update: the release is running, and one check did not pass. A run whose Job finished without recording anything reads as “never reported” — which is a different fact from a failure.
Settings → Maintenance shows the same schedule read-only.
What you control
Section titled “What you control”You choose the maintenance window — the time of day and the time zone updates run in. That is the extent of it: there is no approval queue, no version pinning, and no pause. Eligible releases apply on their own once their preflight checks pass, and an install that has fallen behind moves straight to the newest release rather than working through the intermediate ones.
To change the window, rerun the installer with GREENLIGHT_UPDATER_SCHEDULE (a five-field cron expression, default 0 3 * * *) and GREENLIGHT_UPDATER_TIMEZONE (an IANA zone name, default Etc/UTC) set in its environment. Values you do not restate keep their last setting, so a later rerun for anything else leaves the window alone.
Staying current is what keeps one supported version to reason about and lets a security fix reach your install the night it ships, so it is not an opt-in setting. If you need a change freeze for an audit or a peak season, talk to us rather than looking for a switch.
Apply an upgrade
Section titled “Apply an upgrade”- Read the release notes. They cover migrations, rollback limits, and any policy changes.
- Let it run. The update applies at your configured maintenance time. Nothing is required of you.
- Check the result. Post-upgrade checks confirm the new version responds, audit writes work, and policy checks still pass. Internal Health shows the new version, how the run finished, and the run’s full log if you want to read what it did.
Update now, without waiting for the window
Section titled “Update now, without waiting for the window”Internal Health carries two actions for organization administrators:
- Preview update checks for a newer release, verifies it, runs the pre-checks, and produces the infrastructure plan — then stops. Nothing is applied. It is the safe way to see what an update would do.
- Apply now performs the update immediately, running exactly the same steps the scheduled run would.
Both do the same work as the nightly run, under the same customer-owned identity, with the same audit trail — the only difference is who decided the timing. Only one update runs at a time: while one is in progress the actions are unavailable and the page says so. A scheduled run that lands during an update you started this way is not held off — it stops at pre-checks and tries again the next night. Both are recorded in the audit log with who asked, which action they chose, and whether it started; a refused attempt is recorded too.
Neither action lets you change what gets applied. There is no way to pick a different version, alter install settings, or skip a step from the dashboard — changing settings is still a rerun of the installer. And there is no pause: staying current is not an opt-in setting.
Rollback
Section titled “Rollback”Helm uses an atomic rollout, so a failed application rollout keeps the previous Greenlight workloads running. Infrastructure changes are applied separately and may already have completed or still be converging; the dashboard reports that state and a later idempotent run reconciles it.
Some successful releases cannot be rolled back afterwards, because a database migration has already moved forward. The release notes say so before the release applies, and recovery past that point is a forward fix rather than a rollback.
Capacity
Section titled “Capacity”App capacity autoscales within its configured range, so ordinary demand needs no attention. If your apps are pressing against the top of that range, Internal Health says so and identifies it as a platform-capacity issue rather than an application bug. Changing the range itself is a rare administrator action.
Permissions and limits
Section titled “Permissions and limits”| Cloud | Permission boundary |
|---|---|
| Azure | Dedicated Greenlight resource group |
| GCP | Dedicated Greenlight project |
| AWS | Dedicated Greenlight member account |
Automatic updates depend on the cluster they run in, so they cannot recover a cluster that has been deleted or made unreachable. Those situations are genuine disaster recovery, and the runbook covers them.
Rarely, an update needs something only you can supply — usually a new setting no release can pick a sensible default for. When that happens the update stops with nothing changed, and the dashboard tells you what is needed and what to do next.
Agent plugin releases
Section titled “Agent plugin releases”Plugin releases update the Skills body, MCP configuration, and the agent-specific marketplace wrappers. Your own Knowledge is never touched, and Greenlight updates the plugin content in your marketplace repositories for you.