Network

Bridges and NICs are staged, not live

Editing a node’s network bridges, or a guest’s NIC, doesn’t touch the running configuration immediately. Every change (create, edit, delete) writes into a staged configuration first. Nothing on the wire changes until you explicitly apply.

Applying needs the node’s name, typed out

Applying staged network changes is the one network action that runs as a job, and it’s the one that asks you to type the node’s name to confirm, not just click a generic “yes.” A bad bridge configuration can take a node off the network entirely, with no way to reach it in-band to fix it afterward, so the confirmation is deliberately more friction than a normal confirm dialog.

Reverting is cheap

Reverting staged changes needs no confirmation at all, because all it does is discard the staged file; nothing has been applied yet, so there’s nothing risky to undo.

Guest NICs

A container or VM’s own NICs are read and edited from the app or VM page, following the same stage-then-apply model as node bridges.