A helper container in a running co-located group needs a new image — what does the platform actually replace, and at what cost?

## Replacement happens to the group The group is the unit the platform manages, and that holds for updates as firmly as it holds for placement and deletion. There is no operation that swaps one member's image inside a running group. What exists is: declare a new spec, and the platform brings up a **new group instance** matching it and removes the old one. Every member in that new instance is started fresh, including the ones whose declaration did not change at all. This surprises people because the mental model underneath is often 'a group is a little machine and the members are services on it' — and on a machine you would restart one service. A group is not that. It is an immutable bundle that gets reissued. ## What a replacement instance does not inherit - **The address.** The new instance is reachable at a new address. Anything that cached the old one is holding a stale value. - **The contents of the shared scratch area.** The new instance gets a fresh, empty area. Whatever the previous instance left there is gone. - **The completed work of setup members.** They run again, from the beginning, for the new instance — including any fetch or preparation step they perform. - **Anything held in a member's writable layer.** Each member starts from its image, as it did the first time. | | In-place member restart | Group replacement | |---|---|---| | Trigger | a member's process exits | a changed spec | | Scope | that member only | every member | | Address | unchanged | new | | Shared scratch area | kept | fresh and empty | | Setup members | not re-run | re-run | Getting this pair the right way round is the whole point. A crash is handled in place and cheaply; a spec change is handled by discarding the instance. Describing a crash as a replacement, or a spec change as a restart, gets both the cost and the surviving state wrong. ## What the coupling costs The interesting consequence is not mechanical, it is operational. Once two components are members of one group: - **Release cadences merge.** If the helper ships weekly and the indexer ships quarterly, the indexer now restarts weekly. For a process with a large in-memory index, a warm cache or a slow start-up, that is the expensive part of the whole system being paid on someone else's schedule. - **Blast radius merges.** A bad helper image does not degrade a helper — it takes the group's instances down as they roll, and the main workload with them. - **Rollback merges.** Reverting the helper means reverting the group's spec, so the main member is restarted a second time to undo a change that was never about it. - **Start-up cost is paid again.** Every replacement re-runs setup members and re-warms anything the members build at start-up. None of that is an argument against co-location. It is the price of the shared address and the shared scratch area, and when a member genuinely needs those, the price is worth paying. ## How to decide what goes in the group The question to ask about any candidate member is narrow: **does it need the group's address, or the group's scratch area?** A component that must be reachable as the same address as the main workload, or that must read and write the same files, has a real claim. A component that only needs to run somewhere near the workload does not — it can be its own workload, released and restarted on its own schedule, without dragging the main process along. When the answer is yes but the cadence mismatch is painful, the usual moves are to stabilise the frequently-changing member — take its behaviour from configuration rather than from a new image where that is possible — or to accept the restarts explicitly and make the main process cheap to restart, which is worth doing anyway. Platforms differ in how a replacement is sequenced: some start the new instance before stopping the old one, others stop first. That choice belongs to the workload's update policy, not to the group model. What does not differ is the unit being started and stopped: it is the entire group, every time.