September 11, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
You need a predictable address when a server runs Laravel, MySQL, or a reverse proxy behind a firewall rule. DHCP leases change after reboots or router updates, and that breaks SSH bookmarks, cron jobs, and payment gateway IP allowlists. To configure a static IP on Ubuntu with Netplan, you edit a YAML file under /etc/netplan/, define the interface, address, gateway, and DNS, then apply with netplan apply. This guide walks through the full workflow on Ubuntu 22.04 and 24.04 LTS—the releases I run on production VPS and EC2 instances for client sites. If you are still building the host, start with the Ubuntu server setup guide first.
Quick answer: Configure a static IP on Ubuntu with Netplan by creating or editing a YAML file in
/etc/netplan/, setting addresses, routes, and nameservers under network.ethernets, running sudo netplan try, then sudo netplan apply after confirming connectivity.What do you need before you configure a static IP on Ubuntu with Netplan?
Netplan is the default network renderer on modern Ubuntu Server. It reads YAML from /etc/netplan/*.yaml and hands configuration to systemd-networkd or NetworkManager. Most headless VPS images use networkd. Desktop installs often use NetworkManager. Check before you edit.
Gather these values from your hosting panel, router, or current DHCP lease. You cannot guess them on a remote server.
- Interface name — usually
eth0,ens3, orenp0s3 - Static IPv4 address — one unused host address inside your subnet
- Prefix length — often
/24(netmask 255.255.255.0) - Default gateway — typically
.1on the subnet - DNS resolvers — provider DNS, Cloudflare
1.1.1.1, or Google8.8.8.8
Run these commands on the server while you still have working network access:
ip -br link show
ip -4 addr show
ip route show default
resolvectl status
ls -la /etc/netplan/The interface with an IP today is the one you will configure. Note the gateway and DNS from the output. On cloud VPS hosts, the provider assigns a fixed gateway and subnet—copy those from the control panel, not from home-router conventions.
For broader context on interfaces, routing, and DNS on Ubuntu, see the Ubuntu network configuration guide. If you manage servers for clients in Nepal, predictable IPs also simplify Linux system administration when you whitelist office egress for SFTP or database access.
How do you configure a static IP on Ubuntu with Netplan step by step?
Work as root or with sudo. Back up existing files before you touch anything. A single typo in YAML can drop all network access on a headless VPS.
Step 1: Back up and identify the active Netplan file
sudo cp -a /etc/netplan /etc/netplan.backup.$(date +%F)
sudo ls /etc/netplan/
sudo cat /etc/netplan/50-cloud-init.yamlCloud images often ship 50-cloud-init.yaml. Some providers regenerate it on reboot. If that file says "do not edit" in a comment, create a higher-priority file such as 99-static.yaml. Netplan merges files; lexicographic order decides precedence.
Step 2: Confirm the renderer
grep -r renderer /etc/netplan/Server images typically show renderer: networkd. Match that in your new file. Mixing renderers across files causes silent failures.
Step 3: Write the static IP YAML
Replace ens3 and the addresses with your values. This example fits a typical /24 LAN or VPS subnet:
sudo nano /etc/netplan/99-static.yamlnetwork:
version: 2
renderer: networkd
ethernets:
ens3:
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.8YAML indentation matters. Use two spaces per level. Tabs break parsing. The /24 suffix is CIDR notation—it replaces the old netmask field from ifupdown days.
For IPv6, add an address under addresses and a matching route if your provider assigns a prefix. Many Nepal ISPs still ship IPv4-only business lines, so IPv4-only configs remain common on office servers.
Step 4: Validate syntax before apply
sudo netplan generate
sudo netplan --debug applynetplan generate catches YAML errors without touching live interfaces. Fix any parser message before you proceed. The official Netplan reference documents every key if your provider uses non-standard fields like match or set-name.
How do you apply and verify Netplan changes without losing SSH access?
Never run a blind netplan apply over your only SSH session on a production box. Use netplan try first. It applies the config temporarily and reverts unless you confirm within two minutes.
- Open two SSH sessions to the server (or use console access from your VPS panel).
- Run
sudo netplan tryin the first session. - From the second session, ping the gateway and an external host.
- Run
curl -4 ifconfig.meif you expect outbound NAT—static IP on the interface does not always equal your public IP on cloud NAT setups. - Press Enter in the first session to confirm, or wait for automatic rollback.
- Run
sudo netplan applyonce you are satisfied.
Verify the result:
ip -4 addr show ens3
ip route show default
ping -c 3 192.168.1.1
ping -c 3 1.1.1.1
resolvectl query google.comAfter networking is stable, harden the host. Static IP work often happens during initial provisioning alongside UFW firewall setup, Nginx installation, and MySQL installation. Several sister sites I deploy with Deployer 7 and GitLab CI—legal-tech portals like Notary Kathmandu—run on Ubuntu VPS hosts where the database and app share a private subnet with fixed addresses.
On AWS EC2, the instance private IP often stays fixed even with DHCP in the OS. You still configure a static IP in Netplan when you run custom VPC routing or peered database servers. Always cross-check the Ubuntu Server network documentation for your exact image version.
What are common Netplan YAML mistakes and how do you fix them?
Most failures I see on client servers trace back to a handful of repeatable errors. The symptoms look like "network unreachable" or DNS resolution timeouts after reboot.
Wrong interface name after kernel upgrade
Predictable interface names depend on PCI paths. Cloning a VM or moving a disk can rename ens3 to ens5. Run ip link after hardware changes and update YAML.
Missing default route
Setting addresses without routes leaves the host isolated on the LAN. You can ping neighbours but not the internet. Always include to: default and the correct via gateway.
Duplicate or conflicting Netplan files
Two files configuring the same interface with different settings produce unpredictable merges. List all files with ls /etc/netplan/ and consolidate into one authoritative file. Remove cloud-init overrides if you manage IP manually—edit /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg to set network: {config: disabled} when appropriate.
Using deprecated gateway4 syntax
Older tutorials show gateway4: 192.168.1.1. Modern Netplan on Ubuntu 22.04+ prefers the routes block. Deprecated keys may still parse today but will break on a future release.
DNS works locally but not for PHP or Laravel
Application-level DNS depends on systemd-resolved. After Netplan changes, run resolvectl status and confirm your nameservers appear. If queues or cron jobs fail to reach APIs, stale resolver config is a common cause on supported production servers.
Validate YAML formatting with a quick sanity check—paste your config into the JSON and YAML formatter tool locally before you upload it. Netplan is YAML, not JSON, but structure-aware editors catch indentation problems early.
| Scenario | Recommended mode | Why |
|---|---|---|
| Public web server (Laravel, WordPress, Symfony) | Static private IP + provider elastic/public IP | Firewall rules, load balancers, and SSL validation depend on stable routing |
| Database server on private VLAN | Static IP | App servers reference the DB by IP in legacy configs and backup scripts |
| Home lab or VirtualBox guest | DHCP reservation or static | Static avoids URL changes when testing PHP on Ubuntu vhosts locally |
| Desktop Ubuntu with Wi-Fi | NetworkManager + DHCP | Netplan delegates to NM; static Wi-Fi is rare outside corporate LANs |
| Cloud EC2 with auto-assigned private IP | Often keep provider DHCP | Private IP is already stable; configure static only for custom VPC designs |
When should you use a static IP versus DHCP on Ubuntu production servers?
Use a static IP when other systems depend on your address staying the same. That includes database replication, Redis on a separate box, NFS mounts, VPN tunnels, and third-party API allowlists. Payment gateways in Nepal—eSewa, Khalti, ConnectIPS—sometimes require you to register outbound server IPs for callback verification.
Stick with DHCP when the provider manages addressing and your server has no downstream dependents. Many managed WordPress hosts fit this model. You still pin the public DNS A record to the provider's elastic IP without touching Netplan.
After you set a static IP, document it in your runbook alongside SSH port, PHP version, and backup schedule. Future you—or the next developer—will need those four facts during a 2 a.m. outage. Pair this with Ubuntu server backup strategies and security best practices so the host stays reachable and recoverable.
For a full production stack walkthrough—web server, PHP-FPM, database, and deploy keys—read Symfony deployment on Ubuntu VPS or server hardening for Ubuntu web servers. The Netplan step is usually day-one work before you install packages with apt update.
Desktop and NetworkManager note
Ubuntu Desktop 24.04 often uses NetworkManager as the Netplan renderer. You can still define ethernets in YAML, but many admins prefer nmcli connection modify for Wi-Fi interfaces. Server guides focus on networkd because headless images dominate VPS and bare-metal hosting. Match the tool to the image you installed.
Cloud-init override on recurring reboots
If your static IP disappears after reboot, cloud-init is probably rewriting network config. Disable its network module and keep a single 99-static.yaml. Then run sudo netplan apply and reboot once during a maintenance window. Confirm persistence before you close the ticket.
Hosting clients often buy VPS plans from local or international providers—see domain registration and hosting for the operational side. A static IP on the private interface costs nothing extra; the public elastic IP is what providers bill monthly, often Rs 300–800 (~USD 2–6) on smaller plans.
Key Takeaways
- Gather interface name, IP, prefix, gateway, and DNS from
ip addrand your provider panel before editing Netplan YAML. - Use
renderer: networkdon headless Ubuntu Server and prefer the modernroutesblock over deprecatedgateway4. - Always run
sudo netplan trywith a second SSH session open before committing changes on remote VPS hosts. - Disable cloud-init network overrides if static settings revert after reboot on cloud images.
- Choose static IPs for database, cache, and app servers that other machines reference by address in firewall or config files.
- After networking is stable, continue with firewall hardening, web server setup, and documented runbooks for production reliability.
People Also Ask
Where are Netplan configuration files stored on Ubuntu?
Netplan reads YAML from /etc/netplan/. Files end in .yaml and process in lexicographic order. A common pattern is 50-cloud-init.yaml from the provider plus 99-static.yaml for your manual static IP override.
What is the difference between netplan try and netplan apply?
netplan try applies configuration temporarily and rolls back unless you confirm within about 120 seconds. netplan apply writes the config permanently. Use try first on remote servers to avoid locking yourself out after a bad gateway or prefix.
Can you configure a static IP on Ubuntu without rebooting?
Yes. Netplan applies changes live through systemd-networkd or NetworkManager. Run sudo netplan apply after a successful netplan try. Reboot only when diagnosing cloud-init conflicts or driver-level interface renaming.
Does a static private IP change my public IP address?
Not automatically. On NAT VPS platforms, the public IP is assigned by the provider's elastic IP or SNAT layer. Your Netplan static address is usually the private RFC1918 address inside the VPC. Confirm outbound public IP with curl -4 ifconfig.me after apply.
Next steps for a stable Ubuntu server
You can configure a static IP on Ubuntu with Netplan in under ten minutes when you have accurate network facts and a safe apply workflow. The payoff is fewer surprise SSH failures, cleaner firewall rules, and database connections that survive reboots. On production Laravel stacks I maintain—including booking platforms like Adventure Third Pole Trek—fixed private addresses are baseline infrastructure, not an optional tweak.
Once the address is set, lock down the host with fail2ban, tune performance per the Ubuntu server performance guide, and keep a cheat sheet of essential terminal commands for your team. If you want hands-on help provisioning or hardening a VPS for a business-critical app, contact us or review enterprise application development services for a scoped deployment plan.
Frequently Asked Questions
Netplan reads YAML from /etc/netplan/. Files end in .yaml and merge in lexicographic order. Providers often ship 50-cloud-init.yaml; you add a higher-priority file such as 99-static.yaml to override DHCP with a static address.
netplan try applies configuration temporarily and rolls back unless you confirm within about 120 seconds. netplan apply commits it permanently. Always use try first on remote VPS hosts so a bad gateway does not lock you out.
Yes. Netplan applies changes live through systemd-networkd or NetworkManager. Run netplan apply after a successful netplan try. Reboot only when diagnosing cloud-init conflicts or interface renaming after hardware changes.
Gather five values from your hosting panel, router, or current DHCP lease—you cannot guess them on a remote server. You need the interface name (often eth0, ens3, or enp0s3), an unused static IPv4 address, prefix length (commonly /24), default gateway, and DNS resolvers. Run ip -br link show, ip -4 addr show, ip route show default, resolvectl status, and ls -la /etc/netplan/ while you still have working access. On cloud VPS hosts, copy gateway and subnet from the control panel, not home-router conventions. Check whether your image uses renderer networkd or NetworkManager before editing.
Work as root or with sudo and back up /etc/netplan first—a YAML typo can drop all network access on a headless box. Copy the directory with a dated backup, list existing files, and read 50-cloud-init.yaml if present; create 99-static.yaml when cloud-init warns not to edit the provider file. Confirm the renderer with grep -r renderer /etc/netplan/ and match it in your new file. Write network version 2, set dhcp4 false, add addresses with CIDR suffix, define routes with to default and via gateway, and list nameservers. Validate with netplan generate, then netplan --debug apply only after netplan try succeeds on Ubuntu 22.04 or 24.04 LTS.
Never run a blind netplan apply over your only SSH session on production. Open two sessions—or use the VPS console—and run netplan try in the first. From the second, ping the gateway and an external host like 1.1.1.1, and run curl -4 ifconfig.me if you need to confirm outbound public IP on NAT platforms. Press Enter in the first session to confirm before the two-minute rollback, then run netplan apply. Verify with ip -4 addr show, ip route show default, ping tests, and resolvectl query google.com. On stacks where the app, web tier, and database share a private subnet, stable routing here prevents surprise SSH and replication failures after reboot.
Wrong interface names after a kernel upgrade or VM clone are frequent—run ip link after hardware changes and update YAML. Setting addresses without a default route leaves the host LAN-only; always include to default with the correct via gateway. Duplicate files configuring the same interface produce unpredictable merges, so consolidate into one authoritative file. Older gateway4 syntax still parses on Ubuntu 22.04 but is deprecated; use the routes block instead. DNS can look fine at the OS level yet fail for PHP or Laravel if systemd-resolved is stale—run resolvectl status after apply. YAML indentation must use two spaces per level; tabs break parsing.
Use a static IP when other systems depend on your address staying the same: database replication, Redis on a separate box, NFS mounts, VPN tunnels, firewall rules, load balancers, and third-party API allowlists. Payment gateways in Nepal such as eSewa, Khalti, and ConnectIPS sometimes require registered outbound server IPs for callback verification. Stick with DHCP when the provider manages addressing and nothing downstream references your private IP—many managed WordPress hosts fit this model, pinning public DNS to an elastic IP instead. AWS EC2 private IPs are often stable even with OS-level DHCP; configure Netplan statically only for custom VPC routing or peered database designs.
Not automatically. On NAT VPS platforms, Netplan sets the private RFC1918 address on the interface while the public IP is assigned by the provider elastic IP or SNAT layer. A static private IP and a stable public routable address are separate concerns. After apply, confirm outbound public IP with curl -4 ifconfig.me if payment callbacks or API allowlists depend on it. Document both private and public addresses in your runbook alongside SSH port and backup schedule so the next developer has what they need during a late-night outage.
Cloud-init is usually rewriting network configuration on boot, overriding your manual Netplan file. Disable its network module by setting network config disabled in /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg when you manage IP manually. Keep a single authoritative 99-static.yaml, remove conflicting overrides, run netplan apply, and reboot once during a maintenance window to confirm persistence. Some providers regenerate 50-cloud-init.yaml on every boot if you edit it directly despite warning comments—higher-priority files exist precisely to avoid that fight. Confirm the address survives reboot before closing the ticket.
Match the renderer already declared in your image. Headless Ubuntu Server and most VPS images use renderer networkd; mixing renderers across Netplan files causes silent failures. Ubuntu Desktop 24.04 often uses NetworkManager, where admins sometimes prefer nmcli for Wi-Fi instead of hand-editing ethernets YAML. Server guides focus on networkd because headless images dominate VPS and bare-metal hosting for Laravel, MySQL, and reverse-proxy stacks. Before writing static config, run grep -r renderer /etc/netplan/ and copy that value exactly into your new file.
Modern Netplan on Ubuntu 22.04 and 24.04 LTS prefers a routes block over the deprecated gateway4 key. Define to default with via set to your subnet gateway—typically .1 on a /24 LAN or the value your VPS panel assigns. Setting addresses alone without routes leaves the host able to ping neighbours but unable to reach the internet. The /24 CIDR suffix on addresses replaces the old netmask field from ifupdown-era configs. Run netplan generate before apply to catch parser errors, and validate gateway reachability with ping before confirming netplan try on a remote session.
A static private IP on the interface costs nothing extra on typical VPS plans. Providers bill monthly for a public elastic or routable IP, often Rs 300–800 (~USD 2–6) on smaller plans. Netplan work addresses the private side inside your VPC or LAN; pinning a public address is a separate control-panel step. For Nepal businesses buying local or international VPS hosting, budget the elastic IP line item separately from the base server fee when payment gateways or office egress whitelisting require a fixed outbound address.
DHCP leases change after reboots or router updates, breaking SSH bookmarks, cron jobs, database connections referenced by IP, firewall rules, and payment gateway IP allowlists. When a Laravel app, MySQL, or reverse proxy sits behind UFW or a provider firewall, predictable private addresses keep tiers reachable across reboots. Gateways such as eSewa, Khalti, and ConnectIPS may require registered outbound IPs for callback verification. On production stacks I maintain, fixed private addresses are baseline infrastructure—not an optional tweak—before installing PHP-FPM, Nginx, and Deployer-driven deploy pipelines.
Application-level DNS depends on systemd-resolved, not just the nameservers line in Netplan. After apply, run resolvectl status and confirm your resolvers—provider DNS, Cloudflare 1.1.1.1, or Google 8.8.8.8—appear correctly. Test with resolvectl query google.com. If ping to 1.1.1.1 works but hostnames fail, the nameservers block is missing or malformed in YAML. Laravel queues and cron jobs calling external APIs often surface stale resolver config before interactive SSH tests do. Fix Netplan nameservers, re-run netplan apply, and verify again before debugging application code.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
