Collect the provider-approved address, prefix, route and DNS values. Back up all relevant Netplan files and record the current interface identity and renderer. Keep independent console access and a second connection available before editing a management interface.

1. Inspect the existing YAML and current network state. Check whether a cloud-generated file will be recreated at boot and use the provider-supported persistent change path.
2. Edit the correct configuration with valid YAML indentation. Use the actual interface match/name and assigned values; do not copy another server's address or gateway.
3. Run sudo netplan generate to validate and generate backend configuration. Resolve errors before applying.
4. Use sudo netplan try where supported to apply with a confirmation window. Test the new connection, route and DNS from the intended network before confirming.
5. If the trial expires or is cancelled, verify both runtime and on-disk configuration actually reverted. Known limitations mean the automatic rollback is not a substitute for console access.
6. After acceptance, confirm persistent files contain the intended state and perform a planned reboot test when appropriate.

From the Ubuntu server console or an authorised shell, capture the existing interface and route information before editing YAML. Netplan status availability depends on the installed version. These commands display configuration and runtime state without applying an address change.

sudo netplan get
ip -br address
ip route show
ip -6 route show

Read the result: Match the interface name, assigned addresses and default route with the provider's values. Review all contributing YAML files and whether cloud-init owns them. A second default route or a prefix copied from another server can break access even when the YAML syntax is valid.

Prepare the change with a backup and console access. Use the installed version's generate and try workflow for the actual trial, then verify both connectivity and the saved configuration. Automatic timeout rollback has limitations, so never treat it as your only recovery route.

No. It provides a useful confirmation mechanism, but some virtual-device changes and failures need manual recovery. Keep a console and verify the actual rollback state before leaving the change.

Check IP addresses, default and specific routes, DNS resolution and the intended public/private services. Confirm no unintended second default route or address-family regression appeared. Validate that cloud provisioning does not restore an older configuration on restart.

If connectivity fails, use the independent console and recorded files to restore the previous state. Do not blindly reboot while a bad configuration remains on disk. For bridges, bonds and virtual interfaces, follow their specific Netplan limitations and allow time for the network to settle.

• Separating DNS failure from network failure on Linux
• Recovering from an SSH lockout using the server console
• Restricting Ubuntu firewall access without locking out SSH
• Applying Ubuntu Server security updates with a restart plan

• netplan.readthedocs.io: Netplan Try
• netplan.readthedocs.io: Netplan Generate
• netplan.readthedocs.io: Netplan Yaml

• iproute2 ip manual, published by Debian