# Local and remote images
▶
Watch on YouTube
LXD uses an image-based workflow.
Each instance is based on an image, which contains a basic operating system (for example, a Linux distribution) and some LXD-related information.
To download images, LXD uses [image registries](https://canonical.com/lxd/docs/latest/reference/image_registries/index.html.md#ref-image-registries).
An image registry is a server-side entity that points to a source of images, such as a [simple streams](https://git.launchpad.net/simplestreams/tree/) server or another LXD server.
LXD comes pre-configured with a set of [built-in image registries](https://canonical.com/lxd/docs/latest/reference/remote_image_servers/index.html.md#remote-image-servers) for the most common image sources, and you can [add your own](https://canonical.com/lxd/docs/latest/howto/image_registries/index.html.md#howto-image-registries).
LXD uses the [Go TLS stack](https://pkg.go.dev/crypto/tls) to connect to the image sources.
You can also create your own images, either based on an existing instance or a rootfs image.
Because image registries are managed on the server, all clients of a LXD server (and all members of a cluster) share the same set of image sources.
#### NOTE
In earlier versions of LXD, images were downloaded through client-side *remotes*.
Downloading images now goes through image registries instead.
In the LXD command-line client, remotes are still used to connect to other LXD servers, but no longer to source images.
For backwards compatibility, older clients that still reference a remote image source keep working, as long as a matching image registry exists on the server (LXD auto-creates one for a small set of well-known public image sources).
Once an image is downloaded, it is stored in the local image store.
You can copy local images to other LXD servers and use a local image to create a remote instance.
Each image is identified by a fingerprint (SHA256).
To make it easier to manage images, LXD allows defining one or more aliases for each image.
## Caching
When you create an instance using an image from a registry, LXD downloads the image and caches it locally.
It is stored in the local image store with the cached flag set.
The image is kept locally as a private image until either:
- The image has not been used to create a new instance for the number of days set in [`images.remote_cache_expiry`](https://canonical.com/lxd/docs/latest/server/index.html.md#server-images:images.remote_cache_expiry).
- The image’s expiry date (one of the image properties; see [Edit image properties](https://canonical.com/lxd/docs/latest/howto/images_manage/index.html.md#images-manage-edit) for information on how to change it) is reached.
LXD keeps track of the image usage by updating the `last_used_at` image property every time a new instance is spawned from the image.
## Auto-update
LXD can automatically keep images that come from an image registry up to date.
#### NOTE
Only images that are requested through an alias can be updated.
If you request an image through a fingerprint, you request an exact image version.
Whether auto-update is enabled for an image depends on how the image was downloaded:
- If the image was downloaded and cached when creating an instance, it is automatically updated if [`images.auto_update_cached`](https://canonical.com/lxd/docs/latest/server/index.html.md#server-images:images.auto_update_cached) was set to `true` (the default) at download time.
- If the image was copied from another server using the [`lxc image copy`](https://canonical.com/lxd/docs/latest/reference/manpages/lxc/image/copy/index.html.md#lxc-image-copy-md) command, it is automatically updated only if the `--auto-update` flag was specified.
You can change this behavior for an image by [editing the `auto_update` property](https://canonical.com/lxd/docs/latest/howto/images_manage/index.html.md#images-manage-edit).
On startup and after every [`images.auto_update_interval`](https://canonical.com/lxd/docs/latest/server/index.html.md#server-images:images.auto_update_interval) (by default, every six hours), the LXD daemon checks for more recent versions of all the images in the store that are marked to be auto-updated and have a recorded source registry.
When a new version of an image is found, it is downloaded into the image store.
Then any aliases pointing to the old image are moved to the new one, and the old image is removed from the store.
To not delay instance creation, LXD does not check if a new version is available when creating an instance from a cached image.
This means that the instance might use an older version of an image for the new instance until the image is updated at the next update interval.
## Special image properties
Image properties that begin with the prefix `requirements` (for example, `requirements.XYZ`) are used by LXD to determine the compatibility of the host system and the instance that is created based on the image.
If these are incompatible, LXD does not start the instance.
The following requirements are supported:
| Key | Type | Default | Description |
|---------------------------|--------|-----------|---------------------------------------------------------------------------------|
| `requirements.secureboot` | string | - | If set to `false`, indicates that the image cannot boot under secure boot. |
| `requirements.cgroup` | string | - | If set to `v1`, indicates that the image requires the host to run cgroup v1. |
| `requirements.nesting` | bool | - | If set to `true`, indicates that the image cannot work without nesting enabled. |
## Related topics
How-to guides:
- [Images](https://canonical.com/lxd/docs/latest/images/index.html.md#images)
Reference:
- [Image format](https://canonical.com/lxd/docs/latest/reference/image_format/index.html.md#image-format)
- [Image registries](https://canonical.com/lxd/docs/latest/reference/image_registries/index.html.md#ref-image-registries)
- [Built-in image registries](https://canonical.com/lxd/docs/latest/reference/remote_image_servers/index.html.md#remote-image-servers)