How to Configure a Static IP on Ubuntu with Netplan

To configure a static IP on Ubuntu, identify the active interface, edit the correct file under /etc/netplan/, define the address, prefix, gateway, and DNS, then validate with netplan generate and test it with netplan try. Check routing and DNS separately before closing your SSH session.

Why a Static IP Still Matters on Ubuntu

At three in the morning, “the server is down” often turns out to mean “the address changed.” A DHCP lease can be perfectly healthy and still be the wrong choice for a web server, DNS service, VPN endpoint, or monitoring target.

A static address gives the machine a predictable local or public IP after a reboot. That predictability matters to SSH access, DNS records, firewall rules, reverse proxies, and monitoring checks. If a DHCP address changes, several unrelated services can stop matching at once.

Ubuntu Server can manage networking through different tools depending on the release and installation method. On Ubuntu 18.04 and many later installations, Netplan reads YAML files and generates configuration for either NetworkManager or systemd-networkd. Indentation and the interface name are just as important as the address itself.

For private networks, RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. A server connected directly to the Internet must use the address, prefix, and gateway assigned by its provider instead.

Confirm the IP, prefix, gateway, and DNS values with your provider before assigning anything. Guessing the gateway is how a valid YAML file becomes a useless network configuration.

Find the Netplan File Before Editing It

Netplan configurations normally live in /etc/netplan/. The filename depends on the image and installation method; common examples include 00-installer-config.yaml, 50-cloud-init.yaml, and 99-netcfg.yaml.

ls -l /etc/netplan/
sudo sed -n '1,160p' /etc/netplan/*.yaml

Multiple YAML files can make the result difficult to predict. Netplan processes configuration files by name, so a later file can affect keys defined in an earlier one. If cloud-init generated the file, editing it directly may also mean losing the change at the next boot.

Back up the directory and inspect the merged configuration before making changes:

sudo cp -a /etc/netplan /etc/netplan.backup.$(date +%F-%H%M)
netplan get
networkctl status 2>/dev/null || true
nmcli device status 2>/dev/null || true

netplan get shows the merged configuration on Netplan versions that provide that subcommand. networkctl is useful with systemd-networkd, while nmcli device status usually tells you more when NetworkManager is the backend.

Start with inventory. It is cheaper than recovering a lost SSH session.

Write the Static IPv4 Configuration

In the example below, the interface is ens18, the address is 192.168.1.50, the prefix is /24, and the gateway is 192.168.1.1. Replace all of them with values from your own network.

ip -br link
ip -br address

You may see names such as ens18, enp1s0, or eth0. Do not choose lo; that is the loopback interface. I use a small, nearly unmodified vim configuration on servers because an editor that is available everywhere is worth getting used to.

sudo vim /etc/netplan/50-static-ip.yaml

Netplan’s format uses version: 2 for this configuration structure:

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 9.9.9.9

dhcp4: false disables IPv4 address assignment through DHCP. The prefix is part of the address: 192.168.1.50/24 is equivalent to the 255.255.255.0 netmask. The default route is defined under routes, rather than the older gateway4 form.

The DNS entries control name resolution only. They do not create a default route, and they cannot repair a missing gateway. That distinction has saved me from blaming DNS for a routing mistake more than once.

Replace every example value before applying the file. The interface name is the one people most often leave unchanged.

YAML Is Small, but Indentation Is Configuration

YAML uses spaces to represent structure. A tab character or an extra space can move a key to the wrong level and make the file invalid. Here, ens18 belongs under ethernets, while dhcp4 and addresses belong under ens18.

sudo netplan generate

This validates the configuration and generates backend files without directly changing the live network connection. If it reports an error, compare the interface name with ip -br link and check the file for tabs.

Run it before touching the connection. It catches syntax and schema problems, not an incorrect gateway or VLAN.

Apply the Change Carefully Over SSH

Running netplan apply from a remote SSH session can cut off access immediately. A wrong interface name is enough. So is a gateway that belongs to another network.

The interactive command applies the configuration temporarily and asks you to confirm it:

sudo netplan try

Confirm the change only after the new address and route work. If you do not confirm before the timeout, Netplan attempts to revert the configuration. That rollback is useful, but it is not a universal safety guarantee; keep VNC, a serial console, or your provider’s web console available for critical VPS changes.

When you have local or out-of-band access, apply and inspect the result:

sudo netplan apply
ip -4 address show dev ens18
ip route
resolvectl status

ip -4 address confirms the address, ip route shows the default route, and resolvectl status displays resolver information. A successful ping does not prove that DNS works.

I test these changes first on my Dell OptiPlex 7050 running Proxmox, where a failed experiment stays away from customer systems. I once concentrated on valid YAML and missed that the gateway was outside the configured subnet. The generated file was clean; the route was useless. Syntax validation is not network validation.

Test the Network in Layers

Check the local address, gateway, external connectivity, and DNS separately:

ip -4 addr show dev ens18
ip route get 192.168.1.1
ping -c 4 192.168.1.1
ping -c 4 1.1.1.1
dig +short A example.com

If the gateway does not answer, inspect the prefix, VLAN, virtual switch, cabling, and gateway value. If 1.1.1.1 responds but dig +short A example.com returns nothing, routing probably works while DNS needs attention. A firewall can block ICMP, so ping is evidence, not a final verdict.

For a closer look at the route and resolver:

ip route show default
resolvectl query example.com
sudo ss -tulpen

Test SSH from another machine too. SSH commonly listens on TCP 22, although your server may use another port. You can check reachability with:

nc -vz 192.168.1.50 22

Changing the SSH port is not a security policy by itself. Restricting source addresses, using key authentication, and monitoring logs matter more.

For the network math behind prefixes and host ranges, see What Is CIDR? A Practical Guide to IP Range Calculation. It explains why /24 and /32 behave differently and why the gateway must belong to the reachable network.

Test the gateway, external connectivity, DNS, and service ports independently. One successful ping is not a health check.

Adding IPv6 Without Guessing

If your provider supplies IPv6, add it beside the IPv4 definition. The address 2001:db8::50/64 is reserved for documentation and is not a real Internet-routable address. Use the IPv6 address, prefix, and gateway supplied for your server.

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.50/24
        - 2001:db8::50/64
      routes:
        - to: default
          via: 192.168.1.1
        - to: ::/0
          via: 2001:db8::1
      nameservers:
        addresses:
          - 1.1.1.1
          - 2606:4700:4700::1111

Do not guess the IPv6 route. Some providers use router advertisements or DHCPv6 instead of static routing, and the required Netplan settings depend on that design. An incorrect IPv6 default route can make some applications stall while IPv4 continues working.

Ask the provider which IPv6 method is in use before selecting dhcp6, accept-ra, or a static route. IPv6 is not the place for copy-and-paste optimism.

Common Netplan Errors

“Invalid YAML” or an indentation error

Tabs, missing colons, and list items at the wrong level are usual causes. Run netplan generate on the server before sending configuration containing private details to an external YAML validator.

“Cannot find device”

The interface name in the YAML file does not exist. Find the current name with ip -br link. Cloud images can also use matching rules or cloud-init settings, so inspect those when interface names change unexpectedly.

The gateway cannot be reached

The address and gateway may not belong to the same subnet. For example, 192.168.1.50/24 cannot directly reach 192.168.2.1. Check VLAN tagging, the virtual switch, and whether the provider requires an additional route.

DNS does not work

If ip route is correct but hostnames do not resolve, inspect resolvectl status and the /etc/resolv.conf link. On many Ubuntu installations, systemd-resolved manages that path through a symbolic link, so overwriting the file manually may not survive.

Cloud-init writes the old setting back

If the configuration reverts after reboot, cloud-init may be responsible. Check:

cloud-init status --long
sudo tail -n 100 /var/log/cloud-init.log

Do not disable cloud-init completely without understanding the provider image. Other first-boot tasks may depend on it.

After the network is working, continue with the application layer. How to Install and Configure Nginx on Ubuntu covers the service, listening socket, and site checks that should follow an IP change.

Read the error output and logs first. A failed network command is not, by itself, a reason to reboot.

Roll Back a Static IP Change

If the new configuration breaks connectivity, enter the provider’s console first. Copy the backup back, regenerate the backend files, and apply the old configuration:

sudo cp -a /etc/netplan.backup.2026-09-27-1200/. /etc/netplan/
sudo netplan generate
sudo netplan apply
ip -br address
ip route

Replace the backup directory with the one you actually created; the timestamp above is only an example. If one file overrides another, list every YAML file in /etc/netplan/ and keep unused files somewhere safe before removing them.

A provider snapshot can shorten recovery time before a major change, but it is not a substitute for a configuration backup or console access. See What Is a VPS Snapshot? A Guide to Point-in-Time Backups for the limits of snapshots.

Keep the YAML backup, console details, and rollback commands ready before changing a production VPS. Recovery planning belongs before the outage.

The Workflow I Use

First, confirm the address, prefix, gateway, DNS servers, and IPv6 method. Then inspect the interface and every file under /etc/netplan/. Back up the directory before editing.

Run netplan generate for syntax and schema checks. Use netplan try when changing a remote machine, but keep out-of-band access available. Afterward, check the address, route, resolver, SSH port, and application ports separately.

When I work over SSH, I open a second session to the same server. It is not a replacement for a console, but it sometimes keeps a small mistake from becoming a long recovery exercise. On critical machines, I schedule the change during maintenance and confirm that monitoring alerts are working before I begin.

The official Netplan documentation is the primary reference for syntax, backends, and route definitions. Ubuntu Server documentation explains how Netplan relates to cloud-init and the available network services. Commands copied from an old blog post deserve a check against the documentation installed for your release.

A static IP change is finished only when it survives a controlled reboot and the expected services still listen on their ports. I now include that reboot in the maintenance window. Finding a bad route after the window closes is a lesson I do not need to repeat.

Verify the address, route, resolver, SSH access, and application ports after the reboot. Then leave the backup where the next tired administrator can find it.

Check These Before Applying the Change

• Confirm the IP address, prefix, gateway, and DNS values with your provider.
• Identify the active interface with ip -br link.
• List and read all YAML files under /etc/netplan/.
• Back up /etc/netplan/ before editing anything.
• Run netplan generate and fix every reported error.
• Apply remotely with netplan try when possible.
• Test the address, route, DNS, SSH port, and application services separately.

Frequently Asked Questions

Sources

• Ubuntu Server Documentation – Networking — documentation.ubuntu.com
• RFC 1918 – Address Allocation for Private Internets — rfc-editor.org
• RFC 4291 – IPv6 Addressing Architecture — rfc-editor.org