Netplan on Ubuntu: A Pro's Guide to YAML Networking

Table of Contents

The Mystery of the Missing /etc/network/interfaces

For anyone who grew up managing Debian or older Ubuntu releases, muscle memory leads you straight to /etc/network/interfaces the moment a server loses a heartbeat. You expect a familiar list of eth0 or ens33 configurations. On modern Ubuntu Server editions like 22.04 or 24.04 LTS, however, opening that file usually reveals a blank screen or a lonely comment telling you to look elsewhere.

This shift initially caused plenty of headaches for sysadmins. I once deployed a cluster of 20 web nodes and spent half an hour wondering why my legacy config edits vanished after every reboot. I was effectively locked out of my own remote instances. The issue wasn’t a bug. It was a complete overhaul of the Linux network abstraction layer.

Why Ubuntu Switched to Netplan

Canonical introduced Netplan to act as a high-level translator. Instead of writing complex, low-level scripts for systemd-networkd or NetworkManager, you now define your intent in a single YAML file. Netplan reads this file and generates the specific backend configurations for you.

Ubuntu Server typically uses systemd-networkd as the default renderer, while Desktop versions lean toward NetworkManager. This unified syntax is powerful, but it demands precision. YAML is notoriously picky about whitespace. A single tab character instead of two spaces will stop your network stack from loading entirely.

Finding Your Config Files

Your network definitions live in /etc/netplan/. You will usually find a file with a name like 01-netcfg.yaml or 50-cloud-init.yaml. The specific numbers at the start just determine the loading order if you have multiple files.

Before you touch anything, identify your hardware’s logical names. Run the ip link command to see what the kernel sees:

ip link show

Look for identifiers like enp0s3 or ens18. You must use these exact strings in your YAML file, or the configuration will fail to attach to the hardware.

Basic DHCP Configuration

If your server lives in a standard lab or a public cloud VPC where DHCP handles the heavy lifting, your config stays lean. A standard DHCP setup looks like this:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true

In this hierarchy, network is the root, and version: 2 is the current standard. Every level must be indented by exactly two spaces. Do not use tabs, or Netplan will throw a syntax error.

Setting a Static IP Address (The Modern Way)

Production servers almost always require static IPs. Whether you are running a database cluster or a web proxy, IP persistence is vital for internal routing. I have used the following template for hundreds of production deployments without a hitch.

Here is a verified static IP configuration for Ubuntu 22.04 and 24.04:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      addresses:
        - 10.0.0.50/24
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]
      routes:
        - to: default
          via: 10.0.0.1

Crucial Syntax Updates:

addresses: This requires CIDR notation. Use /24 for a standard 255.255.255.0 subnet mask.
nameservers: You can list multiple DNS providers inside the brackets, separated by commas.
routes: The old gateway4 key is officially deprecated. Modern Netplan uses the routes block to define the default path to your gateway IP.

The “Safety Net” Command

Applying network changes over SSH is like performing surgery on yourself. One typo and you are cut off from the server, often requiring a physical trip to the data center or a serial console login. Netplan solves this with the “try” feature.

Always run this command instead of applying changes blindly:

sudo netplan try

This command applies the config but starts a 120-second countdown. If you don’t press Enter to confirm, Netplan assumes you lost connectivity and automatically rolls back to the previous working settings. It is the single most important tool for remote admins.

Troubleshooting Indentation and Logic

When netplan apply fails, the culprit is almost always a formatting error. Since YAML doesn’t support tabs, ensure your text editor is configured to insert spaces. If you see an “Invalid YAML” error, double-check your columns.

To see what’s happening under the hood, use the debug flag:

sudo netplan --debug apply

This output reveals how Netplan translates your YAML into the actual files found in /run/systemd/network/. If the YAML is valid but the IP isn’t showing up, the debug logs will tell you if the backend daemon is rejecting the parameters.

Handling Multiple Interfaces

Modern servers often split traffic between a public internet port and a private backend network. Netplan manages this by adding secondary entries under the ethernets key:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.10.15/24

In this scenario, enp0s3 pulls a dynamic IP for internet access. Meanwhile, enp0s8 stays locked to a static private IP for local database traffic. Because enp0s8 lacks a gateway, the system correctly routes all external traffic through the DHCP-provided gateway on the first interface.

Summary

Moving to Netplan feels like a chore if you are used to the old ways, but it brings much-needed structure to Linux networking. Treating your network as a declarative YAML file fits perfectly into a modern “Infrastructure as Code” workflow. Just remember to keep your spaces consistent and always use netplan try to avoid accidental lockouts.