LiveChat 
Support 
How to Change the Hostname on Debian (hostnamectl, /etc/hostname, /etc/hosts)
So you’ve spun up a fresh Debian box and it’s still called something forgettable like `debian` or `localhost`, or maybe your provider stamped it with a random string. Let’s fix that together. In this tutorial we’ll change the hostname on Debian properly — applying it live, persisting it across reboots, and updating the one file everyone forgets so you don’t end up staring at a cryptic `sudo` error.
I’ll walk through each command and show you exactly what you should see in the terminal. Pair-programming style: you run it, I’ll tell you what good looks like.
Key Takeaways
• On modern Debian (which ships systemd), the primary command is `sudo hostnamectl set-hostname newname` — it applies the change immediately *and* persists it by writing `/etc/hostname`.
• You must also update `/etc/hosts`. Debian maps the machine’s own name to the special 127.0.1.1 line (not 127.0.0.1). Skip this and every `sudo` command warns: `unable to resolve host`.
• Verify with `hostnamectl` or `hostname`. The shell prompt only updates after you log out and back in (or reboot).
• Use a short name for the static hostname; the FQDN (fully qualified domain name) lives in `/etc/hosts`.
For the distro-agnostic overview, see our companion piece . This post zooms in on Debian’s specifics.
What is a hostname on Debian, and why does it matter?
A hostname is the human-readable name your machine answers to on a network — the thing you see at your shell prompt (`user@webserver01:~$`) and what shows up in logs, mail headers, and monitoring dashboards.
Debian distinguishes a few flavors of hostname, and `hostnamectl` exposes them:
- Static hostname — the persistent name stored in `/etc/hostname`. This is the one you usually want to change.
- Transient hostname — a runtime value the kernel holds; can be set by DHCP and resets on reboot.
- Pretty hostname — a free-form label (spaces and emoji allowed) for display purposes only.
Getting the hostname right matters most on servers: mail delivery, reverse DNS (rDNS), TLS certificates, and clustered services all key off a correct, resolvable name.
How do I check the current hostname?
Before changing anything, let’s see where we stand. Run:
“`bash hostnamectl “`
You should see something like:
“` Static hostname: debian Icon name: computer-vm Chassis: vm Machine ID: 9f1c8a2b4d6e4f00b1c2d3e4f5061728 Boot ID: a1b2c3d4e5f60718293a4b5c6d7e8f90 Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.1.0-21-amd64 Architecture: x86-64 “`
That `Static hostname: debian` line is our target. You can also use the classic command:
“`bash hostname “`
“` debian “`
Good — current name confirmed. Now let’s change it.
How do I change the hostname on Debian with hostnamectl?
This is the modern, recommended way. Because Debian uses systemd, the `hostnamectl` utility is available out of the box and is the single source of truth.
Pick your new name — I’ll use `webserver01`. Run:
“`bash sudo hostnamectl set-hostname webserver01 “`
You won’t see any output. That’s normal — `hostnamectl` is quiet on success. Don’t panic, it worked. Let’s verify:
“`bash hostnamectl “`
“` Static hostname: webserver01 Icon name: computer-vm Chassis: vm … “`
There it is — `Static hostname: webserver01`. Behind the scenes, `hostnamectl set-hostname` did two things for you: it set the live kernel hostname *and* wrote the new name into `/etc/hostname`. So the change is both applied now and persistent across reboots. That’s the whole reason we prefer it over the old `hostname webserver01` command, which only changes the running value and forgets everything on reboot.
Want to peek at the file it wrote?
“`bash cat /etc/hostname “`
“` webserver01 “`
Just the short name, one line, no domain. That’s exactly how Debian wants it.
The Debian-specific gotcha: the 127.0.1.1 line in /etc/hosts
Here’s the part that trips up almost everyone, and it’s genuinely Debian/Ubuntu-specific. Debian uses a special loopback address — 127.0.1.1 — to map your machine’s own hostname, instead of the usual `127.0.0.1`. If you change the hostname but leave the old name sitting on that `127.0.1.1` line, your system can no longer resolve its own name. The symptom is a warning on *every single* `sudo` command:
“` sudo: unable to resolve host webserver01: Name or service not known “`
It’s harmless in the sense that `sudo` still runs — but it’s noisy, it slows commands down (DNS timeouts), and it breaks tools that genuinely need name resolution. Let’s fix `/etc/hosts` so it never appears.
How do I update /etc/hosts on Debian?
Open the file with your editor of choice:
“`bash sudo nano /etc/hosts “`
On a fresh Debian box it typically looks like this:
“` 127.0.0.1 localhost 127.0.1.1 debian
::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters “`
See that `127.0.1.1 debian` line? That’s the one to change. Leave `127.0.0.1 localhost` alone — never touch that. Update the second line to your new name. If you have a domain, list the FQDN first, then the short name:
“` 127.0.0.1 localhost 127.0.1.1 webserver01.example.com webserver01 “`
If the machine has no domain yet, just the short name is fine:
“` 127.0.1.1 webserver01 “`
Save and exit (in nano: `Ctrl+O`, `Enter`, then `Ctrl+X`). Now verify resolution works:
“`bash hostname –fqdn “`
“` webserver01.example.com “`
And run any `sudo` command — `sudo true` is harmless:
“`bash sudo true “`
No warning? Perfect. The resolve-host error is gone for good.
Why hasn’t my shell prompt changed yet?
You’ll likely notice your prompt still reads `user@debian:~$` even though `hostnamectl` reports the new name. That’s expected. Your current shell session captured the hostname when it started, so it keeps showing the old one. To refresh it, log out and back in:
“`bash exit
ssh user@your-server-ip “`
Reconnect and your prompt now reads `user@webserver01:~$`. A full `sudo reboot` works too and is the safest way to confirm everything persists — but a re-login is enough for the prompt.
Methods and files at a glance
Here’s the cheat sheet for changing the hostname on Debian — what each method and file does:
| Method / File | What it does | Persists reboot? |
|---|---|---|
| `sudo hostnamectl set-hostname newname` | Sets static hostname live and writes `/etc/hostname` | Yes |
| `sudo hostname newname` | Sets only the temporary/transient hostname | No (resets) |
| `/etc/hostname` | Stores the static short hostname (one line) | Yes |
| `/etc/hosts` | Maps 127.0.1.1 to your hostname + FQDN | Yes |
| Log out / `reboot` | Refreshes the shell prompt to show the new name | n/a |
The takeaway: `hostnamectl set-hostname` plus an `/etc/hosts` edit is the complete, reboot-safe procedure. The bare `hostname` command is only for quick, throwaway changes.
FQDN vs short name — which goes where?
A quick clarification since it confuses people. The short name (`webserver01`) is what belongs in `/etc/hostname`. The FQDN (`webserver01.example.com`) is assembled from the short name plus the domain, and Debian resolves it via the `/etc/hosts` entry on the `127.0.1.1` line.
You can confirm both:
“`bash hostname # short name hostname –fqdn # fully qualified name hostname –domain # just the domain part “`
“` webserver01 webserver01.example.com example.com “`
If `hostname –fqdn` returns only the short name, your `127.0.1.1` line is missing the fully qualified entry — go back and add it. For a deeper look at the difference, see .
If you’re doing this on a server you actually depend on, the foundation underneath matters as much as the command. DarazHost offers VPS and dedicated servers running Debian (or your distro of choice) with full root access, so you can set your hostname and FQDN exactly as your workloads need — critical for mail deliverability, clean reverse DNS (rDNS), and clear identification across fleets. You get reliable infrastructure and 24/7 support from people who actually know Linux, so when a hostname change needs to line up with a PTR record or DNS zone, there’s someone to help. See and .
Frequently asked questions
Do I need to reboot after changing the hostname on Debian?
No. `hostnamectl set-hostname` applies the change immediately, and the `/etc/hosts` edit takes effect on save. The only thing that lags is your current shell’s prompt, which refreshes after you log out and back in. A reboot is optional — useful mainly to confirm everything persists.
Why do I get “sudo: unable to resolve host” after changing the hostname?
Because you changed the hostname but didn’t update the 127.0.1.1 line in `/etc/hosts`. Debian uses that special address to resolve the machine’s own name. Set it to your new hostname (and FQDN), and the warning disappears. This is the single most common mistake on Debian.
What’s the difference between hostnamectl and editing /etc/hostname directly?
`hostnamectl set-hostname` writes `/etc/hostname` for you *and* updates the live kernel hostname in one step, so the change is active without a reboot. Editing `/etc/hostname` by hand only takes effect on the next boot (or after manually re-applying it). On systemd-based Debian, `hostnamectl` is the cleaner path.
Can I use a fully qualified domain name in /etc/hostname?
You shouldn’t. Debian convention is a short name only in `/etc/hostname` (e.g., `webserver01`). The FQDN is constructed from the short name plus the domain entry on the `127.0.1.1` line in `/etc/hosts`. Putting an FQDN in `/etc/hostname` can confuse some services.
Does this work the same on Ubuntu?
Largely yes — Ubuntu is Debian-based and shares the `hostnamectl`, `/etc/hostname`, and the 127.0.1.1 `/etc/hosts` convention. The steps in this tutorial apply to both. For non-Debian distros (RHEL, Arch, etc.), see our general guide.
