A custom hostname mapping in /etc/hosts can be useful for local services, scripts, SSH, or rsync. If the entry disappears after a reboot, a system-management tool may be regenerating the file.

On cloud images, one possible cause is Cloud-Init. Its manage_etc_hosts setting controls whether it updates /etc/hosts. Cloud-Init does not manage this file by default, so first confirm that this setting is enabled before changing anything.

/etc/hosts

The /etc/hosts file maps hostnames to IP addresses locally, without asking a DNS server. For example:

127.0.0.1 localhost
127.0.1.1 webserver
192.168.1.50 nas
192.168.1.60 backup

A program that resolves nas through the system’s normal name-resolution service can use the local mapping above. The file only affects the machine where it is configured.

Check whether Cloud-Init manages the file

Search the main Cloud-Init configuration and its drop-in directory:

$ sudo grep -Rns 'manage_etc_hosts' /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d/ 2>/dev/null

If you find manage_etc_hosts: true, Cloud-Init rewrites /etc/hosts from a template on each boot. The default is false, which means Cloud-Init should leave the file alone.

Cloud-Init can also be configured by instance user-data or the cloud platform. If the search does not explain the behavior, inspect the generated /etc/hosts file for Cloud-Init comments and review the Cloud-Init logs and your provider’s instance configuration. Other configuration-management tools can also rewrite this file.

Check the current hostname and Cloud-Init status with:

$ hostnamectl
$ cloud-init status --long

To look for the hosts module in the Cloud-Init log:

$ sudo grep -i 'update_etc_hosts' /var/log/cloud-init.log

Option 1: Keep Cloud-Init management and edit its template

Use this approach if Cloud-Init should continue generating the file, for example when the machine’s hostname comes from cloud metadata.

Back up the template before editing it. On Ubuntu, the template is commonly:

$ sudo cp -a /etc/cloud/templates/hosts.debian.tmpl /etc/cloud/templates/hosts.debian.tmpl.bak
$ sudo nano /etc/cloud/templates/hosts.debian.tmpl

Template names can vary by distribution and image. Confirm the relevant template on your system before changing it. Keep the existing template content, including any hostname placeholders such as $hostname or $fqdn, and add your custom entries without duplicating existing lines. For example:

# Custom local mappings
192.168.1.50 nas
192.168.1.60 backup

Cloud-Init renders the template when its hosts module runs. If you do not want to wait for the next boot, follow the procedure for your Cloud-Init version and image; a reboot is one way to run the boot-time update. Avoid manually invoking internal modules unless you know how your image configures them.

Option 2: Let yourself manage /etc/hosts

If the host has a stable configuration and you do not need Cloud-Init to regenerate this file, set manage_etc_hosts to false. Prefer a drop-in file over editing the main configuration:

$ sudo nano /etc/cloud/cloud.cfg.d/99-disable-manage-etc-hosts.cfg

Add:

manage_etc_hosts: false

Before relying on the change, check that another Cloud-Init setting or your cloud provider’s user-data does not override it. Cloud-Init itself remains enabled; this setting controls only management of /etc/hosts.

Then edit the hosts file:

$ sudo nano /etc/hosts

Add the mappings you need, save the file, and verify them. Reboot only when practical, then check again that the entries remain.

Verify the mapping

Read the file:

$ cat /etc/hosts

Then ask the system resolver for a hostname:

$ getent hosts nas

The result should show the address you assigned. If the mapping is important, verify it again after a reboot.

Which option should you choose?

• Keep Cloud-Init managing the file if hostnames or network details are generated dynamically. Add persistent custom entries to the template Cloud-Init uses.
• Set manage_etc_hosts: false if you intentionally manage the file yourself and can maintain it when hostnames or addresses change.

Static entries can become outdated when a server is replaced or its address changes. For multiple hosts or changing infrastructure, DNS or a centralized configuration-management system is usually easier to maintain than editing /etc/hosts on every machine.

References

• Cloud-Init documentation: managing /etc/hosts
• Canonical Cloud-Init example configuration
• Cloud-Init Debian hosts template

If /etc/hosts changes after reboot, confirm which service is writing it before editing configuration. When Cloud-Init has manage_etc_hosts: true, preserve custom entries in its active template; otherwise, manage the file directly and check for other automation. Choose the approach that matches how your host receives its hostname and network settings.

We hope this was helpful.
Keep learning. Keep exploring. Stay secure.