Upgrades a client receives as a pull request

Turnkey is not frozen

A client owns their copy of the platform. Kubernetes, add-ons and providers release every month and security fixes do not wait. Without a delivery channel, a platform starts decaying the day it is handed over.

The vendor-branch pattern

Each client repository keeps a baseline branch that only ever contains rendered baseline code, never client edits. .platform.json records the baseline version and package.

1. A new baseline version is rendered for the client's package onto baseline.
2. A branch from main merges baseline.
3. Git combines the new baseline with the client's own changes; conflicts appear only where the client edited baseline files.
4. The client reviews and merges a normal pull request; plans and policy checks run as for any change.

Moving from one package to the next is the same operation with a different package: the new modules arrive as a pull request, next to the client's own work.

Who runs it

The mechanism is technical, not contractual. A client can run the upgrade themselves from release notes, or have it prepared, reviewed and applied under a support plan. Either way the change is a diff they can read.