New release. Stop the node. Replace binaries. Then find out whether everything you downloaded was actually right.
That is the kind of maintenance routine I assumed Dusk operators simply had to manage carefully. But the latest node-installer flow changed one detail that I think matters more than it sounds. Version 0.5.22 hardened upgrades so replacement artifacts are staged and verified before live files are replaced. Dusk’s upgrade procedure follows the same order: the installer downloads the supported Rusk and wallet binaries, checks them, and only then stops the running Rusk service. It also preserves the operator’s chain state, consensus keys and intentional service overrides rather than treating an upgrade like a fresh node installation. The service stays stopped afterward so the operator can review the regenerated configuration, start Rusk deliberately and confirm peers and block-height progress before calling the job finished.
That is a small but useful operational milestone.
The upgrade window now starts after the replacement is ready, not while the operator is still discovering whether it is usable.
For infrastructure that is supposed to stay available, that ordering is worth more than another convenient command.
@Dusk_Foundation $DUSK #dusk
That is the kind of maintenance routine I assumed Dusk operators simply had to manage carefully. But the latest node-installer flow changed one detail that I think matters more than it sounds. Version 0.5.22 hardened upgrades so replacement artifacts are staged and verified before live files are replaced. Dusk’s upgrade procedure follows the same order: the installer downloads the supported Rusk and wallet binaries, checks them, and only then stops the running Rusk service. It also preserves the operator’s chain state, consensus keys and intentional service overrides rather than treating an upgrade like a fresh node installation. The service stays stopped afterward so the operator can review the regenerated configuration, start Rusk deliberately and confirm peers and block-height progress before calling the job finished.
That is a small but useful operational milestone.
The upgrade window now starts after the replacement is ready, not while the operator is still discovering whether it is usable.
For infrastructure that is supposed to stay available, that ordering is worth more than another convenient command.
@Dusk_Foundation $DUSK #dusk