OS reload: switching distros without losing your IP

OS reload wipes your VPS clean and re-provisions it from a fresh cloud-init image — different distribution if you want, same one if you just want to start over. Your IP address, IPv6 (if any), hostname, and per-VM hypervisor credentials all survive. Everything on the disk doesn't. This article covers when to use it, what's preserved, what's wiped, and how to trigger it.

What OS reload does

Three steps, all from the customer portal:

1. The VM stops.
2. Its disk is wiped and re-imaged from the cloud-init template for the distro you picked.
3. The VM boots clean: new install, your IP, your hostname, your console credentials in place.

The whole thing takes a few minutes. You sign back in over SSH with whatever password / key was provisioned at first boot — same process as when you first ordered the VPS.

What's preserved

• IPv4 address — same IP you've had.
• IPv6 address (if you had one) — same address.
• Hostname — survives the reload.
• Reverse DNS records — your portal-set PTRs stay configured.
• Hypervisor-side configuration — vCPU count, RAM allocation, disk size, network rate limit, snapshot slots (though existing snapshots are gone — see below).

What's wiped

• Everything on the disk. Filesystems, user accounts, applications, configs, mail spools, databases, SSH host keys, your shell history, the lot.
• Existing snapshots. Snapshots are tied to the disk; replacing the disk drops them. Take an off-host backup of anything you want first.
• SSH known_hosts entries on your local machinewill mismatch the new install's host keys. You'll see a "host key has changed" warning on first SSH after the reload — that's expected. Remove the stale entry with:

  ssh-keygen -R <your-IP>

When to use OS reload

• You want to switch distros. The classic case — Debian to AlmaLinux, Ubuntu to Debian, whatever. Cleaner than trying to in-place "convert" a distro (which is usually impossible).
• The install is too broken to fix. A package upgrade left the system in a weird state, half-removed services, conflicting configs. Sometimes faster to start fresh than to untangle.
• You inherited a VPS and don't trust what's on it. Re-image, start with a known-good baseline.
• You're testing something destructive and want a clean slate. Reload, run the test, reload again.
• Suspected compromise. If you think the VM has been rooted, reload is faster and more reliable than forensic cleanup. Re-deploy the application from a known- good source, restore data from off-host backups.

When NOT to use it

• You haven't backed up anything you need. OS reload doesn't ask twice. If you forget, you lose.
• Minor problems that a snapshot rollback would handle. If you took a snapshot before the breaking change, rolling back is one click and preserves everything else. Reload is the nuclear option.
• Just to upgrade the distro to a new release. Debian / AlmaLinux / Ubuntu all support in-place version upgrades that preserve your data. Reload starts from scratch — useful sometimes, overkill for most upgrades.

Before you reload — the checklist

Have all of these in hand before you click the button:

1. Off-host backup of anything you can't lose. Tar your /etc, your application data, your databases. SCP them to your local machine or a remote backup target.
2. List of installed packages — if you want to recreate the same software stack on the new install. On Debian: dpkg --get-selections > packages.list. On AlmaLinux: rpm -qa > packages.list.
3. SSH key (private) on your local machine if you're going to a distro that uses keys by default (most cloud images now do).
4. Plan for what you'll do first on the new install — see the first-hour-with-lylix-vps article. The new install behaves like a brand-new VPS.

How to trigger an OS reload

1. Sign in to customer.lylix.net, open your service.
2. Click the Reinstall OS tab.
3. Pick the operating system from the dropdown. Available choices:
   • Debian (current stable)
   • AlmaLinux (current release)
   • Ubuntu Server LTS
4. Click Reinstall.
5. Confirm the warning dialog (which spells out that your data will be destroyed).

The page will show a progress indicator. You'll see status updates as the disk is wiped, the new image is dropped in, cloud-init runs, and the VM comes up. When it finishes, you can SSH in.

What happens during the reload

1. The VM stops cleanly (or forcefully if it doesn't respond).
2. The hypervisor unlinks the existing disk image.
3. A fresh cloud-init image for the chosen OS is cloned to a new disk image.
4. Cloud-init runs on first boot: configures the network with your IP, sets the hostname, installs the SSH keys / root password from the welcome data.
5. The VM is fully booted and reachable.

After the reload

1. Remove the stale SSH host-key entry on your local machine (see above).
2. SSH in using the credentials from your most recent welcome email (the original one is usually still valid; if not, check the email history in the customer portal).
3. Walk through the first-hour checklist again — update the system, set up keys, change the root password.
4. Restore your application data from the backup you took beforehand.

Common questions

Do I lose my plan / subscription / billing setup?
No. Reload is purely a disk-and-OS operation. Your account, the product subscription, billing cycle, and contact information aren't touched.

Will my IP change?
No. The reload preserves your IPv4 and IPv6 assignment. If you need an IP change, that's a separate request — open a ticket.

Can I reload to a custom image?
Out of the box, no — the dropdown lists the maintained images. If you have a specific need (a distribution we don't list, a custom base image), open a ticket; we can usually add a cloud-init-ready image to the catalog if upstream offers one.

How long does reload take?
Typically 2-5 minutes from clicking the button to a reachable SSH login, depending on the chosen distro's first-boot scripts. Sangoma's FreePBX image is on the slow end; minimal Debian is fastest.

What if reload fails midway?
The VM will be left in a stopped state. Open a ticket and we'll either retry the operation or investigate (image corruption, storage hiccup, etc.). Your account isn't billed extra and there's no permanent harm.