Change Ubuntu’s hostname with hostnamectl set-hostname new-name and update /etc/hosts so the new name resolves locally. The team that only runs hostname new-name gets a change that does not survive reboot; the team that skips /etc/hosts gets sudo errors and broken app config that resolves to the old name. The two-step pattern takes 30 seconds and avoids both traps.
Table of contents
- The right command: hostnamectl
- Update /etc/hosts to avoid the resolution trap
- Verify the change
- Hostname naming rules
- Cloud provider gotchas
- FAQ
The right command: hostnamectl
hostnamectl set-hostname new-name is the right command for permanent hostname changes. It updates /etc/hostname (which systemd reads at boot) and notifies running services of the change. The team that uses hostnamectl has a hostname that survives reboot and shows up in hostname, hostname -f, and systemd’s logging.
Avoid hostname new-name for permanent changes. The hostname command (without hostnamectl) sets the kernel hostname but does not update /etc/hostname. On reboot, systemd reads /etc/hostname and resets to the original value. The team that uses hostname alone loses the change at the next reboot.
Avoid editing /etc/hostname directly unless hostnamectl is unavailable. Manual edits work but bypass systemd’s notification to running services. The team that uses hostnamectl has the change propagate to services; the team that edits manually has to restart services (or reboot) for the change to take effect.
Update /etc/hosts to avoid the resolution trap
The /etc/hosts file maps hostnames to IP addresses for local resolution. The default Ubuntu /etc/hosts has 127.0.1.1 old-hostname as a placeholder. After changing the hostname, this line still points to the old name, which causes sudo and many apps to fail with ‘unable to resolve host’ errors.
The fix: replace the old name with the new name in /etc/hosts. sudo sed -i 's/old-hostname/new-hostname/g' /etc/hosts. The team that runs this after hostnamectl has a consistent hostname across hostname, /etc/hostname, and /etc/hosts.
Why is 127.0.1.1 used instead of 127.0.0.1? On systems with a real domain name (set via DHCP or static IP), 127.0.1.1 is the local lookup for the system’s own hostname, separate from 127.0.0.1 which is the loopback. The team that uses Ubuntu’s default gets this; the team that edits it out loses the local hostname resolution.
Verify the change
Run hostnamectl to see the current hostname. The ‘Static hostname’ field shows the value from /etc/hostname; the ‘Transient hostname’ shows the kernel value (set by hostnamectl). The team that sees ‘Static hostname: new-name’ has a permanent change.
Run hostname and hostname -f. hostname returns the short name; hostname -f returns the FQDN (requires /etc/hosts or DNS to resolve). The team that sees the new name from both commands has a consistent hostname.
Run cat /etc/hostname to verify the file. The team that sees the new name in the file has the change persisted; the team that sees the old name has a transient change that will not survive reboot.
Run getent hosts new-name to verify local resolution. Returns the IP the hostname maps to in /etc/hosts. The team that sees 127.0.1.1 new-name has correct local resolution; the team that sees nothing or the old IP has a /etc/hosts mismatch.
Hostname naming rules
Hostnames can contain letters, digits, and hyphens. No underscores, no spaces, no special characters. The team that picks web-server-01 has a valid hostname; the team that picks web_server_01 is technically invalid (some services reject underscores).
Length: 1 to 63 characters. The team that picks a 64-character hostname has it rejected by some resolvers. The team that picks db has a valid but possibly-too-short name (conflicts with internal short names).
Case-insensitive but case-preserving. DNS normalizes to lowercase. The team that picks Web-Server-01 and references it in code as web-server-01 works; the team that references it as Web-Server-01 in one place and web-server-01 in another may have issues with case-sensitive tools (rare).
Avoid generic names like localhost, master, node. These conflict with services and conventions. The team that picks app-prod-01 has a descriptive, unique hostname; the team that picks node has a hostname that conflicts with Kubernetes node names.
Cloud provider gotchas
On AWS EC2, the hostname is set by DHCP from the instance metadata. The team that uses hostnamectl on EC2 has the hostname revert on the next DHCP lease renewal (typically every few hours). The fix: disable cloud-init’s hostname handling or set the hostname via cloud-init user-data.
On GCP, the hostname is also set by the metadata server. Same pattern as AWS - the change reverts unless configured to persist. The team that runs GCP sets preserve_hostname: true in cloud-init or uses the metadata hostname field.
On DigitalOcean and other VPS providers, hostnamectl persists. These providers do not have a metadata service that overrides the hostname. The team that uses hostnamectl on these providers has a permanent change.
On Kubernetes nodes, do not change the hostname manually. Kubernetes expects the node name to match the kubelet’s --node-name or be derived from the cloud provider. The team that changes the hostname of a Kubernetes node has kubelet registration broken; fix the node registration, not the hostname.
FAQ
What is the difference between hostname and hostnamectl?
hostname is the legacy command that sets the kernel hostname (transient). hostnamectl is the systemd-aware command that sets the persistent hostname (in /etc/hostname) and notifies running services. The team that uses hostnamectl for permanent changes has changes that survive reboot; the team that uses hostname has changes that do not.
Why does sudo say ‘unable to resolve host’ after a hostname change?
Because /etc/hosts still has the old hostname mapped to 127.0.1.1. The fix: update /etc/hosts to map the new hostname to 127.0.1.1. The team that runs sudo sed -i 's/old-name/new-name/g' /etc/hosts has this fixed.
Do I need to reboot after changing the hostname?
No. hostnamectl set-hostname updates /etc/hostname and notifies running services. Some long-running services (rsyslog, postfix) may need a restart to pick up the new name, but most apps read the hostname lazily. The team that does not reboot has the change take effect immediately for new processes.
Can I change the hostname of a remote server via SSH?
Yes, but be careful: if you change the hostname while logged in via SSH, the connection continues (the IP is what matters, not the hostname). The team that changes the hostname remotely does not lose the SSH connection. The team that depends on hostname-based SSH config (Host blocks with Hostname set) needs to update ~/.ssh/config too.
What is the FQDN of a server?
The Fully Qualified Domain Name - hostname plus domain. Example: web-01.example.com. The team that sets both the hostname (with hostnamectl) and the domain (via /etc/resolv.conf or DHCP) has the FQDN. The team that only sets the hostname has the short name without the domain.
Can two servers have the same hostname?
Yes, but it causes issues: shared /etc/hosts entries, ambiguous logs, monitoring that uses hostname as identifier. The team that runs multiple servers gives each a unique hostname (web-01, web-02). The team that runs the same hostname on two servers has troubleshooting nightmares.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: