Write and Verify Netplan YAML with netplan set

netplan set writes one small, validated YAML change so you can inspect it before you trust it near a live interface. The installed package here is netplan.io 1.1.2-8ubuntu1~24.04.3. Allow about fifteen minutes for a simple DHCP setting, longer if you still need to find the right interface.

You need a shell, Netplan installed, and a configuration key that matches your machine. Writing to real configuration normally needs sudo. The examples use documentation addresses and an interface name you must replace. Netplan validates the YAML it writes, but netplan set does not apply networking by itself.

1. Check the installed command

Start with a read-only check. No elevated privileges needed, and it confirms the syntax this installation actually supports:

$ netplan set --help
usage: /usr/sbin/netplan set [-h] [--debug] [--origin-hint ORIGIN_HINT]
                             [--root-dir ROOT_DIR]
                             key_value

The positional argument is one dotted key and value, such as ethernets.enp1s0.dhcp4=true. The help also documents null as a value for deleting a key. The manpage describes a single value or a whole YAML subtree; both forms get written into Netplan's configuration hierarchy.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...

2. Write a DHCP setting to a named file

Use --origin-hint to choose a recognisable output file. The hint becomes a YAML filename under /etc/netplan; it is not a network interface or a profile you apply:

$ sudo netplan set --origin-hint lab-dhcp \
    ethernets.enp1s0.dhcp4=true

On the installed version this creates or updates /etc/netplan/lab-dhcp.yaml. Netplan may also add the top-level network: mapping and version: 2 when it writes the snippet. Read the result as root, since Netplan configuration files are normally private to root:

$ sudo sed -n '1,80p' /etc/netplan/lab-dhcp.yaml
network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true

Do not reuse a file name already owned by cloud-init or another provisioning system unless you have deliberately chosen that ownership. A separate hint makes the change easier to review and remove later. Files are merged according to Netplan's ordering, so a later file can amend or override an earlier one.

3. Add a list or a subtree

Values can be YAML collections. Quote the whole shell argument so brackets, commas and braces reach Netplan as one value. This adds addresses to the same interface:

$ sudo netplan set --origin-hint lab-dhcp \
    'ethernets.enp1s0.addresses=[192.0.2.10/24, 2001:db8::10/64]'

A complete subtree is useful when several related keys need writing together, for example a second interface using DHCP:

$ sudo netplan set --origin-hint second-interface \
    'ethernets.enp2s0={dhcp4: true, dhcp6: true}'

• Keep the single quotes if the value has shell metacharacters or whitespace.
• Review the generated YAML after each meaningful change rather than building one long command that is hard to audit.

4. Verify the merged configuration before applying it

Read the effective configuration with netplan get:

$ sudo netplan get
network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
      - 192.0.2.10/24
      - 2001:db8::10/64
      dhcp4: true

Your output will include the other files on the machine and the order may differ. What matters is that the intended interface and keys show up in the merged view. If Netplan reports an undefined interface, a duplicate or conflicting setting, or an invalid value, stop and fix the YAML. Do not apply something you have not understood.

$ test_root=$(mktemp -d)
$ mkdir -p "$test_root/etc/netplan"
$ netplan set --root-dir "$test_root" --origin-hint demo \
    ethernets.eth0.dhcp4=true
$ find "$test_root/etc/netplan" -maxdepth 1 -type f -print
/tmp/tmp.XXXXXX/etc/netplan/demo.yaml

--root-dir changes where Netplan reads and writes the configuration root, handy for tests and image-building workflows. It does not activate a real host configuration, and it does not skip validation.

5. Apply only after a network safety check

Writing a file does not change the running network. Applying it can interrupt SSH, change routes, or remove an address, so schedule a maintenance window and keep console access when the change could affect your own connection.

For a remotely administered machine, prefer Netplan's temporary test workflow where it is available, and confirm the result before making it permanent:

$ sudo netplan try

If the test looks good and you confirm it, or you have an approved change window, apply the stored configuration explicitly:

$ sudo netplan apply
$ ip address show enp1s0
$ netplan status enp1s0

These commands are separate from netplan set. A successful write only proves Netplan accepted the setting and produced configuration; it does not prove the renderer brought the interface up or that the route and addresses are correct.

6. Remove a setting or recover a bad file

$ sudo cp --preserve=all /etc/netplan/lab-dhcp.yaml \
    /etc/netplan/lab-dhcp.yaml.before-change

To remove the DHCP key written earlier, pass null with the same key and file hint:

$ sudo netplan set --origin-hint lab-dhcp \
    ethernets.enp1s0.dhcp4=null
$ sudo sed -n '1,80p' /etc/netplan/lab-dhcp.yaml

If that snippet held no other settings, the installed command removes the now-empty generated file. If the change was already applied, removing the key does not undo the running network until you run sudo netplan try or sudo netplan apply with a valid replacement configuration. If a test fails, restore the backup, run sudo netplan get, and only then consider applying the restored state.

An invalid value should fail rather than being treated as a successful change:

$ netplan set --root-dir "$test_root" \
    ethernets.eth0.dhcp4=not-a-bool
Command failed: Error in network definition: invalid boolean value 'not-a-bool'

Use a fresh temporary root for failure tests. Existing invalid files can make a later command fail before it even reaches your new argument, which just distracts from the real error.