Will cloud-init change my hostname back after a reboot?

Not on our images. We set a new name with hostnamectl, rebooted, and also made cloud-init treat the next boot as a brand-new instance. The name stayed both times, and so did our edit to /etc/hosts. A reinstall gives you a fresh system with the original name.

Why does sudo say "unable to resolve host" after I renamed the server?

hostnamectl changes the name but not /etc/hosts, which still maps 127.0.1.1 to the old name. On Ubuntu, sudo then prints "unable to resolve host" before every command. Replace the old name on the 127.0.1.1 line with the new one and the warning goes away.

Should my server use UTC or my local time?

UTC is the safer default: log times from different servers line up and there are no daylight-saving jumps. Switch to your local zone if you want cron jobs and log times to read in your own time. Both work, and you can change it again at any point.

Do I need to set up NTP?

No. Our Ubuntu and Debian images keep the clock in sync with systemd-timesyncd from the first boot. Run timedatectl and look for "System clock synchronized: yes".

Does changing the timezone break my cron jobs?

Cron starts using the new zone right away. On our Ubuntu 24.04 server a job set for 09:48 Tokyo time ran at 09:48:01 Tokyo time, without restarting cron. Check jobs that were written for UTC, though: they now run at that hour of your local time.

How to change the hostname and timezone on a VPS

Rename your server and set its clock to your timezone on Ubuntu, Debian and Windows Server, without the sudo warning that follows a bare hostnamectl, and with cron, logs and NTP checked after the change. Every step tested on our images.

A new server is named after what you typed when you ordered it, and its clock is set to UTC. Both are easy to change. Renaming has one catch: the usual command leaves an old line in /etc/hosts, and on Ubuntu sudo complains about it before every command. This guide fixes both on Ubuntu and Debian and shows the Windows Server commands. We ran every step on our own images.

You need a user with sudo. The Ubuntu setup guide creates one.

1. Check the current name and time

hostnamectl
timedatectl

Our fresh Ubuntu 24.04 server reported its order name as the static hostname, Time zone: Etc/UTC, System clock synchronized: yes and NTP service: active. Debian 12 and 13 looked the same. Clock sync already works, so you don't have to install NTP.

2. Change the hostname

Choose a short name, or a full one if it will match a DNS record you control, like web1.example.com:

sudo hostnamectl set-hostname web1.example.com

That changes the name right away, but /etc/hosts still points 127.0.1.1 at the old one. On Ubuntu this showed up at once:

sudo: unable to resolve host web1.example.com: No address associated with hostname

hostname -f failed the same way. Debian found the name through another route and showed no warning, but its /etc/hosts was just as out of date. Fix the file on both:

sudo sed -i 's/^127\.0\.1\.1 .*/127.0.1.1 web1.example.com web1/' /etc/hosts
grep 127.0.1.1 /etc/hosts
hostname -f

After that sudo was quiet, hostname -f printed web1.example.com and hostname -s printed web1.

The comment at the top of /etc/hosts says the file is managed by cloud-init and your changes may be lost. On our images cloud-init writes it only on the server's first boot. We rebooted, then also made cloud-init treat the next boot as a new instance. The name and our /etc/hosts line survived both.

The hostname only lives on your server. If other machines should reach it by that name, add a DNS record as well: pointing a domain to your VPS covers that. For a mail server, the reverse record matters too: see setting reverse DNS.

3. Change the timezone

List the zones and pick yours. Our server had 497:

timedatectl list-timezones | grep -i tokyo
sudo timedatectl set-timezone Asia/Tokyo
timedatectl

The clock itself doesn't move. Only how times are displayed and how local schedules are read changes. Here is what we saw after switching from UTC to Asia/Tokyo:

What	After the change
`date`, `journalctl`	Tokyo time at once
cron	Used Tokyo time at once: a job set for 09:48 ran at 09:48:01 JST, no restart
`/var/log/syslog` (Ubuntu)	Kept writing UTC times until rsyslog was restarted
`/etc/timezone` (Ubuntu)	Still said `Etc/UTC`

So restart the logger, and anything long-running that prints times, such as your app:

sudo systemctl restart rsyslog

Debian 12 and 13 don't install rsyslog. Their logs live only in the journal, which follows the new zone by itself.

A few older programs read the zone from /etc/timezone rather than the system setting. If one of them still shows UTC, write the same name there and restart that program:

echo Asia/Tokyo | sudo tee /etc/timezone

Before you switch, look through your crontab. A line written as 0 3 * * * for 03:00 UTC will now run at 03:00 Tokyo time, nine hours earlier in real time.

4. Windows Server

On Windows Server 2022, open PowerShell as Administrator. The rename needs a restart:

Rename-Computer -NewName web1 -Restart

Windows computer names are limited to 15 characters, so use the short name here.

For the timezone, find the ID and set it. It applies at once, with no restart:

Get-TimeZone -ListAvailable | Where-Object Id -like '*Tokyo*'
Set-TimeZone -Id 'Tokyo Standard Time'
Get-TimeZone

While you're logged in, it's a good moment to secure RDP.

Which plan

Hostname and timezone cost nothing, so any plan will do: Nano at $3/mo for a small Linux server, Windows-Small at $11/mo for Windows Server 2022. All plans are on the VPS page, and payment is in USDT, USDC or ETH on Base, Ethereum or Polygon.