How to Disable cloud-init on Linux: 4 Safe Methods

Four ways to turn it off, one way to turn it down, and the trap that locks people out.

You probably think disabling cloud-init is as simple as systemctl disable cloud-init.

It often works. Until a package update quietly turns it back on. Or until the next VM built from your image boots with no SSH keys and no network, and you’re left staring at a console you can’t log into.

There are cleaner ways, and the right one depends on why you want cloud-init gone.

By the end of this article, you’ll know the officially supported way to disable cloud-init, how to switch off just the parts that annoy you, how to confirm it’s really off, and when you should leave it alone.

---

First, ask why

cloud-init does most of its work on a new instance’s first boot. It sets the hostname, creates users, installs SSH keys, configures the network, and runs your user data.

So people usually want it off for one of three reasons:

• It keeps changing something. The hostname, hosts, or the network config gets overwritten.
• It slows down boot. For example, it waits on a metadata service that doesn’t exist.
• The server isn’t in a cloud anymore. It was migrated to bare metal or a plain hypervisor.

If it’s the first reason, you probably don’t need to disable cloud-init at all. Skip ahead to “Turn it down instead.”

---

Option 1: The marker file (recommended)

This is the method the cloud-init project itself supports:

sudo touch /etc/cloud/cloud-init.disabled

On the next boot, a small systemd generator that ships with cloud-init sees the file and doesn’t activate any cloud-init services.

See also: Mastering the Linux Command Line — Your Complete Linux Training Course

Why it’s the best choice:

• It survives package upgrades. You haven’t changed any unit files, so there’s nothing for an update to reset.
• It’s easy to undo. Delete the file and reboot.

---

Option 2: The kernel command line

You can also disable cloud-init by adding this to the kernel boot parameters:

cloud-init=disabled

On most systems you’d add it through your bootloader configuration, with grubby on RHEL-family systems or /etc/default/grub on Debian-family ones.

This is handy when you can’t touch the filesystem first, such as rescuing a machine that cloud-init keeps reconfiguring. For permanent use, the marker file is simpler.

---

Option 3: Disable or mask the services

The approach most people reach for first is disabling the systemd units directly. The unit names vary between cloud-init versions, so list them before you change anything:

systemctl list-unit-files 'cloud-*'

Then disable or mask what you find:

sudo systemctl mask cloud-init-local.service cloud-init.service \
  cloud-config.service cloud-final.service

This works, but it’s more fragile than the marker file. Package updates and presets can re-enable disabled units, and future versions may add units you didn’t mask. If you go this way, use mask rather than disable, and check again after upgrades.

---

Option 4: Remove the package

If the machine will never need cloud-init again, you can uninstall it:

sudo dnf remove cloud-init      # RHEL, Rocky, Alma, Fedora
sudo apt purge cloud-init       # Debian, Ubuntu

Removing the package doesn’t undo what cloud-init already did. Its network config files, users, and SSH keys all stay in place. Just remember the network files were written by cloud-init, and from now on they’re yours to maintain.

---

Turn it down instead

The French writer Antoine de Saint-Exupéry wrote that perfection is reached “not when there is nothing more to add, but when there is nothing left to take away.” Often you only need to take away one piece.

Drop a file into /etc/cloud/cloud.cfg.d/ to switch off just that piece:

# /etc/cloud/cloud.cfg.d/99-local-overrides.cfg

# Stop cloud-init from changing the hostname
preserve_hostname: true

# Stop cloud-init from managing /etc/hosts
manage_etc_hosts: false

# Stop cloud-init from writing network configuration
network:
  config: disabled

You keep everything else cloud-init does well, like resizing the root disk on first boot, while removing the part that gets in your way. Files in cloud.cfg.d are also safer than editing cloud.cfg directly, because package updates won’t overwrite them.

---

The trap: disabling it in a golden image

Here’s where people get burned.

If you disable cloud-init inside an image, and then launch new instances from that image, those instances won’t get:

• their SSH keys,
• their hostname,
• their network configuration,
• or any of your user data.

Depending on your platform, you may end up with a VM you can’t reach.

The safe rule: disable cloud-init on a running server after its first boot has finished. Don’t bake the marker file into an image unless every instance built from it gets its access and networking some other way.

---

How to confirm it’s really off

After a reboot, check the status:

cloud-init status --long

On recent versions, you’ll see status: disabled, along with a reason such as disabled-by-marker-file or disabled-by-kernel-command-line. Older versions may report this differently.

You can also confirm nothing ran:

systemctl list-units 'cloud-*' --all

All cloud-init units should be inactive.

---

Turning it back on

To undo Option 1, remove the marker file and reboot:

sudo rm /etc/cloud/cloud-init.disabled
sudo reboot

cloud-init will start again, but it remembers what it already did, so it won’t redo one-time work like creating users. If you actually want a full first-boot run, use sudo cloud-init clean --logs --reboot instead. Be careful: that reruns everything, including your user data scripts.

---

Quick summary

• Want it fully off on a running server? Touch /etc/cloud/cloud-init.disabled.
• Can’t reach the filesystem? Use cloud-init=disabled on the kernel command line.
• Only one behavior bothers you? Override just that setting in cloud.cfg.d.
• Building an image? Think twice before disabling it at all.

Have you had cloud-init surprise you after a migration or an upgrade? Tell me what happened in the comments.