# Images

Source: https://docs.quake.ai/docs/compute/concepts/images
Markdown: https://docs.quake.ai/docs/compute/concepts/images.md

---

# Images

Images give each new instance the same starting point: operating system, tooling, and baseline configuration. The Images service ([OpenStack Glance](https://docs.openstack.org/glance/latest/)) lets you discover, register, and retrieve virtual machine images, upload and share image files, and supply the template Compute uses when it boots an instance.

Glance works with [cloud-init](https://cloud-init.io/) and other platform services so metadata, distribution, and first-boot configuration stay consistent across projects and regions.

## What an image is

An image is a file that captures a disk state: typically an operating system plus optional applications and settings. You use it as a reusable template: each launch gets a fresh copy derived from that template, so teams avoid hand-building machines one by one.

The same image produces the same baseline on each instance, which simplifies patching strategies, compliance, and troubleshooting.

## Capabilities

<Figure size="md" caption="Image lifecycle: build a base image, launch instances, snapshot a known-good state, and promote it as the next baseline">

```d2
direction: right

build: Build image\n(QCOW2)
register: Register in\nImages service
launch: Launch instance
snapshot: Snapshot running\ninstance
derived: Derived image\n(promoted baseline)

build -> register
register -> launch
launch -> snapshot
snapshot -> derived
derived -> launch: reuse
```

</Figure>

The service supports storage of virtual machine images (including QCOW2), discovery and search, registration of new images, retrieval when Compute creates instances, sharing across projects, protections for image data, and integration with the rest of the cloud stack.

In practice you register images with metadata (name, format, size, and related fields) so they can be managed and found. Images can be distributed to multiple locations so instances can be placed closer to users or workloads. You create, list, update, and delete images through the Console, CLI, or API.

When you create an instance, you point Compute at an image; Compute pulls it from the Images service and boots from it. Snapshots of running instances are stored as images, so you can clone a point-in-time state or recover from backup.

Image signing and verification help you trust that an image has not been tampered with between upload and deploy.

## Cloud-init

Images work best with Linux distributions that ship cloud-init. Cloud-init runs on first boot to apply network settings, users, packages, and SSH keys from metadata. That is how key pairs and user data reach the guest without baking secrets into the disk image.

See the [cloud-init documentation](https://cloudinit.readthedocs.io/en/latest/) for modules, networking, and user-data formats.

## Why images matter in your workflow

Reusability means one golden image can launch many instances with identical baselines. Portability means images can move between compatible OpenStack-style environments when you collaborate or migrate. Customization lets you build images that already contain your stack, so instances start closer to bootable.

Snapshots capture running state for backup, migration, or cloning. They trade storage for speed when you need a known-good copy of an instance.

## Relationship to instances and snapshots

An image is the template; an **instance** is a running VM created from that template. Each boot copies the image content into the instance disk (behavior may vary by image format and storage type), then cloud-init and your configuration finish the story. When you snapshot an instance, you produce a new image that encodes disk state at that moment: useful for golden images, migration, or rollback after risky upgrades.

That loop (build image, launch many instances, snapshot the best, promote the snapshot to the next baseline) is how teams standardize environments without manual cloning.

## Practices that keep images useful

Prefer vendor-provided or well-maintained community images when you want predictable updates and security posture. Refresh custom images with patches on a schedule so new launches do not inherit old vulnerabilities. Trim unused packages and files to reduce size, storage cost, and boot time. Harden images (disable unused services, sensible defaults, monitoring agents) so launched instances inherit those choices.

Document what each custom image contains (packages, users, agents) so operators know which image to pick when requirements change.

## Further reading

**On this platform:**

- [Create an image](/docs/compute/how-to/create-image): upload or register a custom image
- [Instance snapshots](/docs/compute/concepts/snapshots): capture running instance state as an image
- [Instances](/docs/compute/concepts/instances): how images become running virtual machines
- [Images console](/reference/compute/console/images): Console reference for image management
- [Images CLI reference](/reference/compute/images-cli): `openstack image` commands

**External resources:**

- [OpenStack Glance documentation](https://docs.openstack.org/glance/latest/): upstream Image service architecture and admin reference
- [OpenStack Image Guide: Obtain images](https://docs.openstack.org/image-guide/obtain-images.html): pre-built cloud images for common Linux distributions
- [cloud-init documentation](https://cloudinit.readthedocs.io/en/latest/): first-boot configuration and user data formats