Test Netplan Changes Safely Before Committing Them

Use netplan try to apply a Netplan YAML change temporarily, check that the machine remains reachable, and confirm it before the deadline. If you do nothing, Netplan attempts to roll the change back. This is particularly useful over SSH, where a bad address, route or renderer setting can end your session.

Before you start

Allow about 10 minutes for a small change, plus enough time to test the affected network paths. You need:

• an account with sudo access;
• a working backup or copy of the Netplan YAML you are about to edit;
• a second way into the machine, such as a console or out-of-band session, if the change affects your only management connection; and
• a clear test for success, such as reaching a gateway, resolving a name, or connecting to a service.

Read the existing files before changing them. Netplan normally reads YAML files from /etc/netplan/, but the exact file names and merged configuration depend on the host.

1. Save the current configuration

Make a private copy outside /etc/netplan/. Replace the example file name with the file you will edit. This does not apply anything and can be run without elevated privileges if your account can read the file.

sudo cp --preserve=mode,ownership,timestamps /etc/netplan/01-netcfg.yaml /tmp/01-netcfg.yaml.before-netplan-try
sudo sed -n '1,220p' /etc/netplan/01-netcfg.yaml

Do not copy this path blindly: a host may have several YAML files, and their names affect merge order. Keep the backup until you have verified the result.

2. Make one small YAML change

Edit the relevant file with an editor. For example, a minimal Ethernet DHCP configuration has this shape; use the real interface name from the machine, not enp1s0 unless that is genuinely present.

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true

Preserve the rest of the host's required settings. YAML indentation is significant. A syntax error or an invalid Netplan key should stop the trial before you confirm anything, but a syntactically valid configuration can still make the interface unreachable.

3. Start the temporary trial

Run the command with elevated privileges. With no extra options, the documented timeout is 120 seconds.

sudo netplan try

Netplan applies the current configuration and waits for confirmation. The timeout starts a short window for testing; it is not a guarantee that every network change will settle immediately.

Checkpoint: test before confirming

While the trial is active, test the result from the machine and, where relevant, from another host. Examples:

ip address show dev enp1s0
ip route
getent hosts example.com
curl --fail --silent --show-error --max-time 5 https://example.com/

Replace enp1s0 and example.com with values that match your system and test plan. A successful command only checks one property. Confirm the management route, DNS, required remote networks and any service endpoint that the change is meant to support.

4. Confirm or let the trial roll back

If all checks pass, answer the interactive confirmation prompt so the new configuration is accepted. Follow the prompt shown by your installed Netplan version; do not assume that closing the terminal means the change was accepted.

If the change is wrong, reject it at the prompt. If you provide no confirmation before the timeout, Netplan automatically attempts to revert the trial. The default 120 seconds can be changed when a service needs longer to settle:

sudo netplan try --timeout 300

The timeout is in seconds. The manpage specifically warns that configurations involving features such as STP can take more than a minute to settle, so choose a window that covers both convergence and testing.

Checkpoint: verify the final state

After accepting or rejecting the trial, check the running state again:

ip address show dev enp1s0
ip route
netplan status

If the trial timed out or was cancelled, treat the result as untrusted until these checks show the expected addresses and routes. The local netplan-try(8) documentation records known rollback bugs and advises verifying whether the network was actually reverted.

Trying a separate configuration file

--config-file adds one YAML file to the usual configuration for the trial. It must use the Netplan YAML format:

sudo netplan try --config-file /tmp/netplan-candidate.yaml --timeout 180

Use a file you have inspected and protect it from accidental edits while testing. This option does not make the temporary file a permanent replacement for the normal files under /etc/netplan/. If you accept the trial, make the intended permanent configuration explicit in the normal Netplan files and check those files before a reboot.

Recovery if the result is wrong

Do not reboot immediately after a failed trial. First confirm what is on disk and whether the running network really reverted:

sudo ls -l /etc/netplan/
sudo sed -n '1,220p' /etc/netplan/01-netcfg.yaml
ip address
ip route

If the rollback is incomplete, use the console or other recovery path and restore the known-good YAML backup, then run sudo netplan apply only after checking the restored file. That command applies the current configuration without the trial's automatic confirmation window, so it is a deliberate recovery action. Verify the network again afterwards.