#dusk $PORTAL is on fire today originally thought upgrading a node on @Dusk meant replacing the binary and restarting the same machine with the same role.

one warning in the operator guide made me rethink that.

@Dusk_Foundation s installer preserves consensus keys, chain state and selected service configuration. But it deliberately regenerates files such as rusk.toml, genesis.toml and the Rusk systemd unit.

More importantly, the operator has to repeat the node’s existing network and feature flags. wait let me book my profit in $CYS

If an archive operator reruns the installer without "--feature archive", the installation is replaced with the default Rusk binary. The machine may still run, connect to peers and advance in block height, yet no longer provide the archive functionality applications were relying on.

thats the part that stuck.

Dusk reduces upgrade risk by downloading and verifying replacement binaries before stopping Rusk. It also leaves the service stopped afterward so the operator can review the generated configuration before bringing it back online.

But automation cant decide which old custom settings remain valid. Dusk specifically warns operators to compare the previous rusk.toml and reapply only the settings they still need, not copy the entire old file over the new configuration.

So a successful installation isnt the same as a correctly restored service.

Does regenerating configuration make Dusk node upgrades cleaner and safer, or make preserving the node’s intended role the most important operator check??

#dusk @Dusk k $DUSK

What matters most after a Dusk node upgrade?