Test Netplan Changes Safely with netplan try

netplan try applies a YAML change temporarily and rolls it back if you never confirm it. That is the safety net you want before pushing a network change over SSH, where a bad address or route can end your session for good.

Before you start

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

• Sudo access on the account you are using.
• A 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.
• A clear test for success, such as reaching a gateway, resolving a name, or connecting to a service.

Read the existing files before you touch them. Netplan normally reads YAML 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/, replacing the example file name with the one you will edit. This does not apply anything and can 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. A minimal Ethernet DHCP configuration looks like this; 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 stops the trial before you can 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 is a short testing window, not a guarantee every network change will settle immediately.

Checkpoint: test before confirming

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

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 matching your system and test plan. Each command only checks one property, so confirm the management route, DNS, required remote networks and any service endpoint 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 whatever prompt your installed Netplan version shows; do not assume closing the terminal means the change was accepted.

If the change is wrong, reject it at the prompt. Give no confirmation before the timeout and Netplan automatically tries to revert the trial. The default 120 seconds can be extended 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 pick 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 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

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 another 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.