Configure a Static IP on Ubuntu with Netplan

By Khimananda Oli | Last reviewed: August 2026

When managing production infrastructure or self-hosted services, relying on DHCP is a liability; you must configure a static IP on Ubuntu with Netplan to ensure consistent connectivity for SSH, databases, and internal APIs. Since Ubuntu 18.04, Netplan has replaced legacy /etc/network/interfaces as the default network configuration utility, using declarative YAML files to define network states. This guide provides the exact syntax, validation workflows, and safety checks needed to assign a permanent address without locking yourself out of the server.

How do I identify the correct network interface for a static IP?

Before you edit any configuration, you must confirm the exact name of your network interface. Modern Ubuntu versions use Predictable Network Interface Names (e.g., enp3s0, ens18) instead of the legacy eth0. Using the wrong identifier is the most common reason a fresh server setup fails to acquire network connectivity after a reboot.

Run the following command to list all interfaces and their current state:

ip -br link show

You will see output similar to this:

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3           UP             08:00:27:a1:b2:c3 <BROADCAST,MULTICAST,UP,LOWER_UP>
docker0          DOWN           02:42:d1:e2:f3:a4 <BROADCAST,MULTICAST>

In this example, enp0s3 is the active physical interface. Ignore lo (loopback) and virtual bridges like docker0 unless you are specifically configuring container networking. If you are working on a VPS or cloud instance, also check your provider’s documentation; some environments inject network config via cloud-init, and manual edits may be overwritten on boot unless you disable that integration.

Finding existing Netplan configuration files

Netplan reads all .yaml files in /etc/netplan/ in lexicographical order. List them to find the active configuration:

ls -la /etc/netplan/

Typical filenames include 00-installer-config.yaml, 01-netcfg.yaml, or 50-cloud-init.yaml. You should edit the existing file rather than creating a new one unless you have a specific override strategy. If multiple files exist, later files can override earlier ones, which often causes confusion when debugging duplicate IP assignments.

What is the correct Netplan YAML syntax for a static IP?

YAML is whitespace-sensitive. A single misplaced space will cause netplan generate to fail silently or produce invalid backend configuration. When you configure a static IP on Ubuntu with Netplan, always use spaces (not tabs) and maintain consistent indentation (typically two spaces).

Below is a production-ready template for a single-interface server. Replace values with your actual network parameters:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
        search:
          - example.com

Key configuration fields explained

• version: 2 — Required. Netplan v2 is the current stable schema. Omitting this triggers deprecation warnings.
• renderer — Use networkd for headless servers and containers. Use NetworkManager only if you have a desktop environment or need Wi-Fi management.
• dhcp4: no — Explicitly disables IPv4 DHCP. If omitted while setting static addresses, both static and dynamic IPs may be assigned, causing routing conflicts.
• addresses — CIDR notation is mandatory. 192.168.1.100/24 is valid; 192.168.1.100 alone is not. For multiple IPs, add additional list items.
• routes — The to: default entry replaces the deprecated gateway4 directive. Always use the explicit route format for forward compatibility.
• nameservers — Define at least two resolvers for redundancy. The search domain allows short hostnames (e.g., db instead of db.example.com).

How do I safely apply and validate Netplan changes remotely?

The biggest risk when you configure a static IP on Ubuntu with Netplan is applying an incorrect configuration over SSH and permanently losing access. Never run netplan apply directly on a remote server without a recovery plan. Instead, use the built-in safety mechanism:

sudo netplan try

This command applies the configuration temporarily and starts a countdown (default 120 seconds). If you do not confirm within that window, it automatically reverts to the previous working configuration. This is your primary defense against lockouts.

1. Validate syntax first: Run sudo netplan generate. If it returns no output, the YAML is syntactically valid. Any error message points to the exact line and column.
2. Test interactively: Run sudo netplan try --timeout 180 to give yourself extra time to verify connectivity.
3. Verify from another terminal: Open a second SSH session or use console access (IPMI, cloud provider console) to ping the new IP or test DNS resolution.
4. Confirm persistence: Once verified, press Enter in the netplan try prompt to make the change permanent. Alternatively, if you’re confident and have out-of-band access, sudo netplan apply commits immediately.

If you do get locked out, use your hosting provider’s VNC/console to log in and run netplan apply again after fixing the YAML, or restore from a backup config. This is why I always recommend keeping a known-good backup: sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak.

How does Netplan compare to legacy networking tools?

Understanding why Netplan exists helps avoid the temptation to fall back on deprecated methods. Many engineers still search for /etc/network/interfaces, but that file is ignored on modern Ubuntu installations unless you manually install and enable the ifupdown package — which introduces unnecessary technical debt.

For server environments — especially those managed via Infrastructure as Code or automated provisioning — Netplan is the only supported standard. Its declarative nature makes it trivial to template with Ansible, Terraform, or cloud-init, ensuring identical configurations across dev, staging, and production.

Troubleshooting common Netplan errors

Even experienced engineers hit these issues when they configure a static IP on Ubuntu with Netplan:

• "Invalid YAML" errors: Usually caused by tabs or inconsistent indentation. Use yamllint to catch these before applying.
• Duplicate IP assignment: Check for conflicting .yaml files in /etc/netplan/. Cloud-init may regenerate 50-cloud-init.yaml on reboot. Disable it with echo "network: {config: disabled}" | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg if managing manually.
• No default route: Verify your routes block uses to: default and not the removed gateway4. Run ip route show to confirm.
• DNS not resolving: Netplan writes to systemd-resolved. Check resolvectl status to verify nameservers are applied. Avoid editing /etc/resolv.conf directly — it’s a symlink managed by the resolver.

Configure a Static IP on Ubuntu with Netplan Reliably

Getting networking right is foundational. When you configure a static IP on Ubuntu with Netplan correctly, you eliminate an entire class of intermittent failures that plague DHCP-dependent servers. The key takeaways are simple: use the modern routes syntax instead of deprecated directives, always validate with netplan try before committing, and understand which renderer your environment requires. For teams managing multiple servers, consider automating this configuration through Ansible playbooks or cloud-init templates to ensure consistency and reduce human error during deployments.

If you’re setting up infrastructure for compliance-sensitive workloads or need help designing audit-ready networking across multi-cloud environments, reach out to discuss your architecture. Stable, predictable networking isn’t optional — it’s the baseline everything else depends on.