Apply Netplan Changes Without Losing Your Network

You will apply the YAML configuration in /etc/netplan to the running system, check what Netplan generated, and keep a recovery path if the change affects your only network connection. Allow about fifteen minutes for a small change, plus a separate recovery window if you are working over SSH.

This guide uses netplan.io version 1.1.2-8ubuntu1~24.04.3 on the local system. The installed command exposes a few options that are not shown in the installed manual page's short synopsis, so the examples call out where version-specific behaviour matters. You need an administrator shell for commands that read or apply system network configuration.

1. Check the command before touching networking

First confirm which executable will run and inspect the installed apply options. These commands are read-only:

$ command -v netplan
/usr/sbin/netplan
$ dpkg-query -W -f='${Package} ${Version}\n' netplan.io
netplan.io 1.1.2-8ubuntu1~24.04.3
$ sudo netplan apply --help
usage: /usr/sbin/netplan apply [-h] [--debug] [--sriov-only]
                               [--only-ovs-cleanup] [--state STATE]

The ordinary form is sudo netplan apply. The manual describes the main sequence: Netplan generates backend configuration, invokes either systemd-networkd or NetworkManager, then may unbind and rebind interfaces that remain down so udev rename rules can run. A rebind can briefly interrupt an interface, even when the YAML edit looks small.

2. Inspect the current YAML and make a reversible change

List the files before editing so you know which configuration is in scope:

$ sudo find /etc/netplan -maxdepth 1 -type f -name '*.yaml' -print
/etc/netplan/01-network-manager-all.yaml

Your file names will differ. Netplan reads YAML files in this directory; use the configuration format documented by netplan(5) rather than guessing keys from another network tool. Copy the directory to a private temporary location before editing. This backup is for recovery, not a second configuration that Netplan will read:

$ backup_dir=/tmp/netplan-before-apply
$ sudo mkdir -p "$backup_dir/etc"
$ sudo cp -a /etc/netplan "$backup_dir/etc/"
$ sudo ls -la "$backup_dir/etc/netplan"

Now edit the intended YAML file with your normal editor. Keep the change narrow. Do not remove a bridge, bond or other virtual device merely because its declaration is no longer in the file; netplan apply is stateless and does not remove those already-created devices.

3. Generate and review backend configuration

Before applying, ask Netplan to generate backend files. This is a separate, useful checkpoint: it can reveal YAML or schema errors without deliberately bringing interfaces down.

$ sudo netplan generate
$ printf 'generate exit status: %s\n' "$?"
generate exit status: 0

For more detail, add the global debug option before the subcommand:

$ sudo netplan --debug generate

A successful generation does not prove that the running network will match your intention. It proves that Netplan accepted the files and generated backend configuration. If it fails, stop here, fix the YAML, and run the same command again. Do not use netplan apply as a syntax-check shortcut when you are working remotely.

$ sudo cp -a "$backup_dir/etc/netplan/." /etc/netplan/
$ sudo netplan generate

4. Apply the accepted configuration

When you have independent access or a tested maintenance window, apply the current files:

$ sudo netplan apply
$ printf 'apply exit status: %s\n' "$?"
apply exit status: 0

Normal success may produce no output. The important result is exit status 0, followed by an independent check of the live network. If you need diagnostics, use:

$ sudo netplan --debug apply

The command invokes the configured backend and may rebind interfaces that remain down. That last step gives udev rename rules an opportunity to run; it is also why an apply can affect the link state after the backend has been invoked.

5. Verify the live result

Check the addresses and routes using tools that describe the running kernel state:

$ ip address show
$ ip route show
$ sudo netplan status

Compare the output with the design you intended: the expected interface is present, it has the expected address, and the default route points to the expected gateway. A successful apply only says that the operation completed; it does not certify reachability to every service or destination.

For a remote host, test from a second session before closing the first one. Check the service or endpoint that matters, not only the local interface:

$ ping -c 2 GATEWAY_ADDRESS
$ getent hosts example.org

Replace GATEWAY_ADDRESS with the real gateway. The lookup test checks name resolution, while the gateway test checks a different part of the path. Neither is a substitute for an application-level health check.

6. Recover from a bad apply

If the new configuration breaks connectivity and you still have console access, restore the saved YAML and apply it:

$ sudo cp -a "$backup_dir/etc/netplan/." /etc/netplan/
$ sudo netplan generate
$ sudo netplan apply
$ ip address show
$ ip route show

The backup path in this example is under /tmp, so it can disappear after a reboot or cleanup job. Once the recovery is confirmed, make a durable copy in your approved change-management location if you need one. Do not leave several experimental YAML files in /etc/netplan without understanding their ordering and combined effect.

If a stale bridge or bond remains after its YAML declaration was removed, Netplan will not remove it automatically. The manual gives ip link delete dev DEVICE_NAME as an example of manual removal, but that is a service-disrupting action. Confirm the exact device name and dependencies first, and run it only during an approved change window:

$ ip link show
$ sudo ip link delete dev DEVICE_NAME

If the device is needed, restore its YAML declaration instead. A reboot also clears transient device state, but it is a larger intervention and should not be used as an unexamined first response.

7. Understand the version-specific apply options

The installed 1.1.2 command also lists --sriov-only, --only-ovs-cleanup and --state STATE. Use these only when their purpose matches the change:

• --sriov-only applies only SR-IOV-related configuration and then exits.
• --only-ovs-cleanup limits the operation to cleaning up old Open vSwitch interfaces.
• --state DIRECTORY supplies a directory containing a previous YAML configuration state. It is useful for the documented virtual-device recovery workflow, but the directory must contain the expected backup layout.

Do not copy these options to an older host without checking that host's own netplan apply --help. The installed manpage documents the ordinary apply workflow and the state-backup idea, while the local help is the authoritative list for this installed binary.