cloud-init: use it, or turn it off on purpose

cloud-init can set SSH keys and the hostname on first boot of a KVM VPS. You do not have to keep it. Either leave it enabled and manage hostname and keys through it, or disable and mask the services so they stay off. Half-editing it usually causes the next reboot to undo your changes.

What cloud-init changes on the guest

On many LogicWeb KVM templates, cloud-init may write authorized keys, set the hostname, and touch a few first-boot defaults. That is convenience, not a requirement for the guest to boot. KVM still starts without it. The pain shows up when you set a name in /etc/hostname and cloud-init rewrites it on the next boot. Mail HELO, reverse DNS, and the shell prompt then disagree, and delivery suffers. Check whether it ran before you assume a random reboot will help.

cloud-init status –long
hostnamectl
systemctl is-enabled cloud-init || true

cloud-init status --long shows whether this boot ran it and whether it reported success. hostnamectl shows the name the system will present if Postfix is not overridden. The unit state tells you if the next reboot will repeat the same work. If status says it is disabled and the hostname still changes, something else is writing the name. Note that in the ticket so we are not chasing the wrong service.

Stop fighting the hostname every reboot

You pick a stable hostname for mail. cloud-init may put the panel guest name or instance id back in place. SPF and PTR still match the name you wanted, while receivers see the name cloud-init wrote. That mismatch often lands mail in junk. Deleting /var/lib/cloud because a blog suggested it is the other common mistake. On the next rebuild you may find injected keys gone and wonder why login broke.

If you want panel-injected keys and a hostname that matches the guest name, leave cloud-init on. Set the hostname in the panel, not only under /etc. If you want a frozen configuration, disable the cloud-init services and mask them so a package update does not bring them back. Then set the hostname yourself, install the keys yourself, and leave /var/lib/cloud alone. Rely on the datasource, or remove the whole path cleanly. Do not edit one piece and hope the rest stays quiet.

What to send if the name still flips

If mail HELO still changes after you think you fixed it, capture hostnamectl before and after a reboot plus cloud-init status --long. That pair shows whether cloud-init ran again and what name the guest settled on. If the guest will not come back at all, the boot console is the next place to look. Same price at renewal still applies to the VPS itself; this is only about how the guest configures on boot.