Every server job that touches the network assumes one thing: the machine is reachable at the same address tomorrow. SSH bookmarks, port-forwarding rules, a WireGuard peer that dials home to your VPS, a monitoring check that pings a host by IP, all of them quietly break the day DHCP hands your server a different lease. A static IP is the fix, and on modern Ubuntu Server the tool for the job is Netplan, the YAML-based network configuration layer that has shipped by default since Ubuntu 17.10.

This guide sets a static IPv4 address on Ubuntu Server 22.04 or 24.04. It takes about ten minutes, needs only SSH access and sudo, and includes the one safety net that keeps a typo from locking you out: netplan try.

Before you start

Gather four values from your own network. Do not copy the examples below verbatim; they describe a typical home LAN, and your network will differ.

  • Interface name, for example eth0 or enp0s3. Ubuntu Server no longer guarantees eth0; check yours.
  • The static address you want, for example 192.168.1.50/24. Pick an address outside your router's DHCP pool so the router never hands it to another device.
  • Gateway, usually your router, for example 192.168.1.1.
  • DNS servers, for example 1.1.1.1 and 8.8.8.8, or your router's address.

You also need a fallback way in. If anything goes wrong, you want console access: a hypervisor console for a VM, your VPS provider's web console, or a keyboard and monitor for a physical box. If you are configuring a remote machine over SSH, read the section on netplan try before you touch anything.

Step 1: Find your interface and current settings

Check what the system currently uses:

BASH
ip -br address
ip route

The first command lists interfaces and their addresses; the second shows the default route, which reveals your gateway. Note the interface name that carries your current address. If you see a DHCP lease on that interface, that is the one you will make static.

Also look at the existing Netplan files so you know what you are replacing:

BASH
ls /etc/netplan/
cat /etc/netplan/*.yaml

On a fresh Ubuntu Server install you will typically find one file, often 50-cloud-init.yaml or 00-installer-config.yaml, containing a dhcp4: true stanza. You will edit that file (or replace its contents), not add a second file that fights it.

Step 2: Back up the current configuration

One command, ten seconds, and it saves you from reconstructing the working config from memory:

BASH
sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak

Use your actual filename from Step 1. If you ever need to roll back, copy the backup over the edited file and run sudo netplan apply.

Step 3: Write the static configuration

Open the file with your editor of choice:

BASH
sudo nano /etc/netplan/50-cloud-init.yaml

Replace its contents with a stanza like this, adapted to your network:

YAML
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Three details matter more than the rest of the file:

  • Indentation is two spaces, and tabs are forbidden. YAML will reject the file, or silently misread it, if you mix tabs in.
  • The /24 suffix is part of the address. It is the subnet mask in CIDR notation: /24 means the first 24 bits are the network, which matches the common 255.255.255.0 home LAN. Leave it off and Netplan will complain.
  • Use routes, not gateway4. The gateway4 key was deprecated in newer Netplan releases and removed in recent ones. The routes form with to: default is the supported way to set a default gateway.

The renderer: networkd line tells Netplan to hand the configuration to systemd-networkd, the default on Ubuntu Server. Desktop installs use NetworkManager instead; if your file says renderer: NetworkManager, keep that line as it is rather than switching renderers mid-flight.

Step 4: Apply safely with netplan try

This is the step that separates a calm afternoon from a locked-out server. Instead of applying directly, run:

BASH
sudo netplan try

Netplan applies the new configuration and starts a countdown, typically 120 seconds. Confirm within that window and the change sticks; do nothing, and it rolls back automatically. If your SSH session freezes the moment you press enter, that is the safety net working: wait for the rollback, and your old address comes back.

Only when netplan try confirms cleanly should you make it permanent:

BASH
sudo netplan apply

Step 5: Verify everything, in order

Do not trust a single check. Work outward from the machine:

BASH
ip -br address
ip route
ping -c 3 192.168.1.1
ping -c 3 1.1.1.1
resolvectl status

You want to see: your new static address on the right interface; a default route via your gateway; replies from the gateway (your LAN works); replies from 1.1.1.1 (your route to the internet works); and your DNS servers listed by resolvectl (name resolution works). Finish with a name lookup:

BASH
getent hosts example.com

If every step answers, reboot once and repeat ip -br address. A static address that survives a reboot is the whole point; a config that only works until the next boot usually means a second Netplan file, or cloud-init, is overwriting yours.

Common traps

Cloud-init overwrites your file. On many VPS images, cloud-init regenerates the Netplan configuration on boot, and your edit vanishes. Check whether your file is managed by cloud-init, and if it is, either set the address through your provider's panel or disable cloud-init's network management for that file. On a cloud VPS, a DHCP reservation in the provider panel is often the saner static address anyway.

Two files, two opinions. Netplan merges every .yaml file in /etc/netplan/ in alphabetical order, with later files winning. A leftover installer file still saying dhcp4: true for the same interface will fight your static stanza. Keep one authoritative file per interface and remove or correct the rest.

The DHCP pool collision. Picking an address inside the router's DHCP range works until the router leases the same address to a phone, and then both devices flap. Either pick an address outside the pool or create a DHCP reservation for the server's MAC address on the router, which is the belt-and-braces version of this whole guide.

Forgetting DNS. A server that can ping 1.1.1.1 but cannot resolve names has a nameserver problem, not a routing problem. Check the nameservers block first, and remember that resolvectl shows what systemd-resolved actually uses, which is the truth that matters.

A note on the alternative: DHCP reservations

If your router supports it, a DHCP reservation achieves nearly the same result with less risk: the server keeps asking DHCP, and the router always answers with the same address. It is a good choice for home labs, but it fails the moment the router is replaced or reset, and it does not help on a VPS at all. For anything you depend on, a real static configuration on the server itself is the durable answer. Once the address is fixed, your UFW firewall rules and SSH hardening stop depending on an address that might move.

Sources

  • Ubuntu Server documentation: Netplan configuration reference
  • Netplan documentation: netplan.io reference and examples
  • man netplan and man netplan-try on Ubuntu 24.04