> ## Content Index
> Fetch the complete content index at: https://snubmonkey.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Keep /etc/hosts Changes After Reboot on Ubuntu.
- URL: https://snubmonkey.com/ubuntu-etc-hosts-persist-reboot/
- Published: 2025-05-09T23:23:20.000Z
- Updated: 2026-10-22T23:11:16.000Z
- Description: If custom entries in Ubuntu’s /etc/hosts disappear after reboot, Cloud-Init may be regenerating the file. Learn how to confirm it, preserve entries in the right template, or turn off only this part of Cloud-Init.
- Author: yannick Coffi
- Tags: how to 🪄, linux 🐧

# 

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:

```text
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:

```sh
$ 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:

```sh
$ hostnamectl
$ cloud-init status --long

```

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

```sh
$ 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:

```sh
$ 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:

```text
# 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:

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

```

Add:

```yaml
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:

```sh
$ 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:

```sh
$ cat /etc/hosts

```

Then ask the system resolver for a hostname:

```sh
$ 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](https://docs.cloud-init.io/en/latest/reference/yaml%5Fexamples/update%5Fetc%5Fhosts.html?ref=snubmonkey.com)
- [Canonical Cloud-Init example configuration](https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config.txt?ref=snubmonkey.com)
- [Cloud-Init Debian hosts template](https://github.com/canonical/cloud-init/blob/main/templates/hosts.debian.tmpl?ref=snubmonkey.com)

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.**