> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ibee.ai/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.ai/docs/_mcp/server.

# Custom images

> Boot a Cloud VM from your own ISO, a snapshot, or a backup recovery point.

In addition to IBEE-curated [OS templates](/docs/infrastructure/cloud-vms/os-images), you can deploy a Cloud VM from a **custom image** — your own ISO, a snapshot you've taken from another VM, or a backup recovery point.

This is the right path for:

* **Migration** — bring a server in from another provider with a snapshot or backup it produced.
* **Golden images** — standardize a build (web server, ML toolchain, security agent) and clone it across many VMs.
* **Niche operating systems** — boot from an ISO not in the template catalog.
* **Disaster recovery** — restore an entire VM, including data disks, from a previous recovery point.

## Sources

The **Operating System** picker on the Deploy page exposes three custom-image tabs:

### ISOs

Mount an ISO and run an interactive install. ISOs include:

* Public ISOs in the IBEE catalog.
* Custom ISOs you've uploaded under **Tools → ISOs**.

After install, the VM keeps the root disk and persists across reboots like any other Cloud VM. See [ISOs](/docs/tools/isos) for upload, attach, and detach steps.

### Snapshots

Manual recovery points captured from another VM ([Create a snapshot](/docs/tools/snapshots/create-a-snapshot)). When you select a snapshot:

* The root disk is cloned to a new disk on the new VM.
* Any captured data volumes from the snapshot set are also restored and **auto-attached** to the new VM.
* For data volumes, mount instructions are surfaced in the snapshot detail view ([Restore a snapshot](/docs/tools/snapshots/restore-a-snapshot)).

Use snapshots when you need an exact, point-in-time clone — including filesystem state — and you control when the snapshot was taken.

### Backups

Scheduled recovery points produced by the [automated backups](/docs/tools/backups/enable-backups) feature. Behaves the same as snapshots at restore time, but the recovery cadence is daily or weekly per the VM's backup schedule rather than ad-hoc. See [Restore from backup](/docs/tools/backups/restore-from-backup).

## When to choose each source

| Source       | Best for                                                              | Notes                                                                    |
| ------------ | --------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **ISO**      | OS not in template catalog; clean install with custom partitioning    | Slowest path — interactive install required.                             |
| **Snapshot** | Cloning a known-good build to many VMs; pre-cutover migration testing | You control the timing and scope (root only, all volumes, or selective). |
| **Backup**   | Disaster recovery; rolling back to a recent automated point           | Schedule-driven; convenient because it runs without action.              |

## Deployment flow

1. Open **Cloud VMs → Create server**.
2. Pick **Region**, **Location**, and **Plan** as usual.
3. Under **Operating System**, switch to **ISOs**, **Snapshots**, or **Backups**.
4. Pick the source from the list. The chip at the bottom of the page updates to reflect the selected image (for example `Snapshot · backup-1`).
5. Continue with **SSH Keys**, **Hostname**, and **Deploy Now**.

## Bring-your-own-image checklist

If you're moving an image in from outside IBEE, verify before booting:

* **virtio drivers** for disk and network are present (Linux) or installed (Windows). KVM uses `virtio-blk` / `virtio-net` by default.
* **cloud-init** (Linux) is installed and enabled — needed for SSH key injection and hostname configuration.
* **DHCP client** is enabled on the primary NIC — public IPs are assigned via DHCP.
* **qemu-guest-agent** is installed if you want guest filesystem metrics.
* The **bootloader** points at the right disk (`/dev/vda` for the root disk on KVM).

If any of these are missing, the VM may boot but be unreachable, or fail to come up at all. Use the [Console](/docs/infrastructure/cloud-vms/power-actions#console) to debug.

## Related pages

* [OS images](/docs/infrastructure/cloud-vms/os-images)
* [ISOs](/docs/tools/isos)
* [Snapshots](/docs/tools/snapshots)
* [Backups](/docs/tools/backups)