Skip to content

Images

Explanation · Updated Jun 2026

Coming from another cloud?

▸AWS·Amazon Machine Images (AMIs)

Amazon Machine Images (AMIs)high

  • Managed via EC2 APIs, not Glance.
  • Region-specific with cross-region copy.
  • Marketplace AMIs may charge hourly fees.
  • Includes block device mapping in AMI.
AWS docs ↗
▸Azure·Compute Gallery image definitions and versions

Azure Compute Gallery image definitions and versionshigh

  • Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
  • Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
  • Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
  • New features like Trusted Launch only in Gallery, legacy managed images deprecated.
Azure docs ↗
▸DigitalOcean·Images (Distributions, 1-Click Apps, Snapshots, Backups, Custom Images)

Images (Distributions, 1-Click Apps, Snapshots, Backups, Custom Images)high

  • DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
  • Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
  • DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
  • DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.
DigitalOcean docs ↗
▸Google Cloud·Machine Images (full VM state capture)

OS imageshigh

  • Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
  • Image families point to latest version; no OpenStack equivalent.
  • Custom images stored in Cloud Storage with licensing fees for premium OS.
Google Cloud docs ↗
▸Hetzner·Images

Imageshigh

  • Includes system images (OS), user images (snapshots/backups).
  • API /v1/images; create via server action create_image (type=snapshot/backup).
  • Billed per GB/month; backups cost 20% of server price.
  • No direct image upload; custom via ISO attach or rebuild.
Hetzner docs ↗

Images

Images give each new instance the same starting point: operating system, tooling, and baseline configuration. The Images service (OpenStack Glance) 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 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#

Build image(QCOW2)Register inImages serviceLaunch instanceSnapshot runninginstanceDerived image(promoted baseline) reuse
Click to zoom
Image lifecycle: build a base image, launch instances, snapshot a known-good state, and promote it as the next baseline

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 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:

External resources:

Quick answers

Related content

Pages

Was this page helpful?