Upgrade and patch
Prepare
Identify the affected cluster, agent, gateway, sandbox runtime, workerd, binding services, hosts, or builder images. Record the current and proposed versions, signed image digests, vulnerability/dependency inventory, compatibility impact, and rollback path. Take required database backups before stateful service changes.
Execute
- Validate the release in a pilot nonproduction canary cluster using representative Nuxt apps and the supported compatibility contracts.
- Run identity, tenant isolation, DB/KV, egress denial, artifact verification, and malicious-fixture checks appropriate to the changed boundary.
- Verify cluster capacity permits rolling updates. Establish monitoring and a named operator with authority to halt the rollout.
- Roll nodes/services in controlled batches while draining workloads and preserving desired-state reconciliation.
- Verify health, routes, policy versions, signing trust, backup freshness, and app request/error metrics after each batch.
- Stop if compatibility or health checks fail. Use the approved service rollback path; separately review any state/schema change that prevents reversal.
- Record versions, digests, affected apps, canary results, rollout times, exceptions, and final health.
Patch boundaries
Keep trusted infrastructure separate from untrusted customer workloads throughout the update. Do not alter an app's pinned compatibility semantics silently. Rebuild application artifacts through the normal source/build/approval chain when a dependency update changes application code.
Acceptance
A completed upgrade requires evidence that the canary and production checks passed, desired and actual state converged, and backups remain recoverable. Preserve previous signed releases for the documented rollback window.