Receiving Managed Upgrades

On the managed data plane, an upgrade is a pull request bumping pinned versions in your repository: automation does the mechanical work of noticing a release and preparing the change, and you decide when each environment takes it. Nothing rolls out until someone in your organization comments /approve on it.

How Upgrade Pull Requests Arrive

A scheduled job seeded in your own repository compares every pinned image against the release catalog daily and opens an upgrade pull request when a tracked image is behind its latest release. The job is deliberately narrow:

• It opens pull requests, never commits. The default branch is yours; automation only ever proposes.
• Each pull request modifies exactly one version file: one layer, one diff, one decision.
• There is at most one open pull request per layer. A newer release updates the open pull request in place, and a manual bump that makes it unnecessary closes it automatically.
• It runs with your repository's own credentials against the public catalog. No Tetrate credential exists anywhere in the loop.
• It sets the three approval checks on every request it opens or updates, so an upgrade always arrives waiting on your /approve and never on nothing.

Because there is one pull request per layer, product defaults and each environment upgrade separately: dev can be a week ahead of prod, and that gap is staging, not drift.

Releasing an Upgrade

1. Open the pull request. The title and body name the component and the versions it moves between.
2. Confirm the diff touches only version entries. Each chart revision and each image is pinned separately, so the diff is exactly the components that move and nothing else; customer files never appear in it.
3. Comment /approve when the environment is ready. An upgrade request touches only a version file, so tetrate-approval is already green and your approval is the last thing it needs: it merges immediately. Approving Changes covers the rest of the commands and the checks behind them.
4. Stage the environments. Releasing the dev environment's pull request first, watching the rollout, then releasing prod is the intended rhythm, not a workaround.

Two commands are worth knowing before the first request arrives. /hold pins a request shut through a change freeze, including one you have already approved, and /unhold releases it when the freeze lifts. /close dismisses a request you do not want now without deciding anything permanent: the next scheduled run opens it again if the versions it carried are still behind.

If a newer release lands before you get to a request, the automation updates that same request rather than opening another, and the new commit clears your approval. Approve again once you have read the new diff: what merges is always what somebody looked at.

Watching the Rollout

From the merge, the loop closes on evidence rather than assumption:

1. ArgoCD picks up the merge on its next sync and rolls the new versions out.
2. The agent reports the new images in its next snapshot, so the containers in the Clusters view show the new versions and the orange Upgrade available markers clear.
3. The next scan no longer finds the fixed CVEs on the new image, so the old image's findings resolve.

Completion is evidence, not assumption

Until the agent observes the new images, the console keeps showing the old version, and that honesty is the feature: a merged-but-stuck rollout stays visible instead of being assumed done.

Freezing an Environment

An image participates in automated bumps because its entry carries its catalog coordinates, the component and variant to track. Removing those coordinates from an environment's version file deliberately freezes that environment: the daily job stops proposing bumps for it until the coordinates are restored. Freezing is the sanctioned way to hold an environment back; hand-editing pins is not, because the automation would immediately propose moving them again.

Freezing and holding answer different questions. Freeze an environment when it should stop being offered upgrades at all; /hold a single request when the upgrade is right but the timing is not.

Chart revision bumps are always human-authored, from Tetrate's side, so a chart change never rides along silently with an image bump.

Next Steps

• Remediate vulnerabilities to see how releasing these pull requests is the managed answer to actionable findings.
• Approve changes for the full command list, the three checks, and the setting that separates approving from merging.
• Work with your repository for the layout the pull requests land in and the customer files they never touch.
• Read Release Catalog for where the daily comparison gets its truth.