Using Netplan try for Safe Network Changes on Ubuntu

The problem: a mis‑typed YAML can lock you out

Editing network configuration on an Ubuntu server is risky. A single indentation error in a Netplan YAML file can cause netplan apply to silently fail, leaving the interface without an address and possibly cutting off SSH access. You need a way to test changes before they become permanent.

Thesis: Netplan’s try command gives you a timed safety net

The netplan try workflow applies the new configuration, waits for you to confirm that connectivity still works, and automatically rolls back if you do not respond within the timeout. This lets you experiment with VLANs, bonds, or address changes without the fear of being locked out.

Worked example: adding a VLAN interface

1. Backup the existing Netplan file (optional but recommended):

   sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

2. Create or edit a Netplan YAML that adds VLAN 10 on eth0 with a static address:

   # /etc/netplan/01-vlan.yaml
   network:
     version: 2
     renderer: networkd   # or NetworkManager on a desktop
     ethernets:
       eth0:
         dhcp4: no
     vlans:
       vlan10:
         id: 10
         link: eth0
         addresses: [192.168.10.5/24]
         gateway4: 192.168.10.1
         nameservers:
           addresses: [8.8.8.8,8.8.4.4]
   

3. Run the safety‑checked apply:

   sudo netplan try

   You will see a prompt similar to:

   Do you want to keep these settings?
   [Y]es (default) / [N]o :

   If you have connectivity (e.g., you can still SSH or ping the gateway), press Y or wait for the timeout (default 120 seconds) to elapse without answering; the system will then roll back to the previous configuration.

4. Verify the new interface after confirming:

   ip addr show vlan10
   ping -c 3 192.168.10.1
   

   If the rollback occurred, the vlan10 interface will not appear and you will be back to the original state.

Trade‑off and limitation

netplan try only works when the backend renderer (NetworkManager or systemd‑networkd) can bring the interface up and down without a full reboot. On some cloud images where cloud‑init overwrites Netplan files on first boot, the rolled‑back state may be temporary; you must preserve your custom YAML via cloud‑init user‑data or the no-cloud datasource. Additionally, the command does not test higher‑level services (e.g., DNS resolution beyond the nameserver list) – you still need to verify those manually.

Actionable closing

Make netplan try your default first step for any network edit on Ubuntu. Keep a backup of the working YAML, use the timeout to confirm connectivity, and only run netplan apply after you have verified that the new configuration works. This simple habit turns a potentially disruptive change into a safe, reversible operation.