> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ibee.co.in/docs/infrastructure/cloud-vms/custom-images/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.co.in/_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:

* **Golden images** — standardize a build (web server, ML toolchain, security agent) and clone it across many VMs.
* **Disaster recovery** — restore a VM from a previous recovery point.
* **Niche operating systems** — boot from an ISO not in the template catalog (see the console limitation below).

## Sources

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

### ISOs

Boot the VM from an ISO you added under **Tools → ISOs**. The **ISOs** tab lists the ISOs available to your account.

> **Warning**
>
> **Interactive installs need a console, which isn't available in the portal yet.** A VM booted from an installer ISO waits for you to step through the installer, and browser console access is still **Coming soon**. Until it ships, use a [template](/docs/infrastructure/cloud-vms/os-images), or a snapshot or backup of a VM you've already built.

See [ISOs](/docs/tools/isos) for adding ISOs and attaching or detaching them.

### 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. Deploying from the **Backups** tab uses the captured **root disk only**. To restore the root and attached data disks together, open the source VM's **Backups** tab and choose **Create New VM** instead. 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    | Needs an interactive console, which isn't available in the portal yet.   |
| **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 **Infrastructure → Cloud VMs** and click **Deploy VM**.
2. Pick the **Location** and **Plan** as usual.
3. Under **Operating System**, switch to **ISOs**, **Snapshots**, or **Backups**.
4. Pick the source from the list. The bottom bar updates to show the selected image.
5. Continue with **SSH Keys**, **Network Configuration**, **Billing**, and **VM Details**, then click **Deploy**.

See [Create a VM](/docs/infrastructure/cloud-vms/create-a-vm) for every field.

## Bring-your-own-image checklist

If you build an image yourself, 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. Browser console access isn't available yet, so check the [Activity feed](/docs/infrastructure/cloud-vms/monitoring#activity-feed) and the VM's firewall group, or rebuild from a known-good snapshot.

## Related pages

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

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