Blue/green cutover
Paired proxy+backend, distinct server keys per instance, three-state close (Closing → soft cutover at 5 min → hard cutover at 15 min), abort conditions, nightly restarts on the same mechanism
Phase
Phase 5
Size
L
Waits on
3
Releases
1
Stories
Not designed yet.
Stories and acceptance criteria are written one Feature at a time. Nothing is missing – this one has not had its pass.
Decisions of record
- Cutover
Stand up a whole new proxy and backend for each deploy, so proxy-level and backend-level changes are both covered. TCPShield's backend flip only affects new connections – existing ones stay established against the old proxy until they disconnect on their own, so there is no single hard-cutover moment to hit.
- Cutover
The old instance moves through three states, not straight to shutdown: Closing (new instance confirmed healthy, old stops accepting anything new), Soft cutover at 5 minutes (everyone not actively doing something is transferred, with a countdown warning), Hard cutover at 15 minutes (everyone still on the old instance, including mid-duel, gets a strong warning and is force-transferred; old instance shuts down once empty).
- Cutover
No forced routing before Closing begins – new joiners only until then.
- Cutover Needs design
Old and new backend need distinct server keys in the API, not the same key – otherwise presence, heartbeats and event delivery start treating two servers as one. Race conditions while both are briefly live need explicit handling in the API, not assumed away. Needs design as part of X1.
- Cutover
Old clients cannot be transferred – the transfer packet needs a 1.20.5+ client to receive it, hence the ViaVersion floor; below that, a normal kick-with-message.
- Cutover
Aborts on error rate, TPS, or a failed health check.
- Cutover
Nightly restarts get the same treatment, not just deploys.
History
- 3 Sept Not started – Seeded from the delivery plan, 2026-09-03.