Images
The Images service lets you retain complete disk images in the cloud for quick access in the future or recover a deleted Linode.
The Images service might help you in the following scenarios:
- If you're a web or software agency that deploys similar starter configurations for clients.
- If you have development workflows that require the same base image for all developers or applications.
- If you have workflows that use cloud-based distributions other than those provided by Akamai Cloud.
Terminology
- Image. An image is a file containing exact content and structure of a data storage device.
- Custom image. A custom image is an image of a Linode you created in Akamai Cloud or an image of an external disk uploaded to Akamai Cloud. Custom images are stored in a specific compute region. They don't expire and they remain on your account until you manually delete them. Technical specification vary, based on whether you create or upload the image.
Example: You pre-configure a disk with the exact software and settings you need for your applications and workloads — what's known as a golden image —and you save it as a custom image. You can quickly deploy that custom image to a new or existing Linode in the future. This saves you the time required to manually set up your entire system after each deployment. - Custom image cloud-init compatible. When creating or uploading an image, you can choose to make the image cloud-init compatible. Many Linode-supported distributions are compatible with it by default, or you may have installed cloud-init. Our Metadata service is designed to be consumed by cloud-init.
- Recovery image. A recovery image is created automatically when a Linode is deleted, for recovery purposes. They have a defined expiration date, after which Akamai Cloud automatically deletes them. The expiration timeline is typically equal to the number of hours the Linode was active, up to 21 days.
Images aren't intended to serve as a full backup solution. For more comprehensive backups, including automated backups, consider using our Backups service.
- Shared image (Beta). A shared image is a custom image that was added to a share group.
- Custom image. A custom image is an image of a Linode you created in Akamai Cloud or an image of an external disk uploaded to Akamai Cloud. Custom images are stored in a specific compute region. They don't expire and they remain on your account until you manually delete them. Technical specification vary, based on whether you create or upload the image.
- Share group (Beta). Share groups enable you to share a custom image with other users of your account. Share groups have the following limits:
- You can create up to 100 share groups.
- Each group can have up to 500 images in it.
- Each group can have up to 25 members added.
To learn more, see Manage image sharing.
- Regions. There are two region types to consider:
- Core compute region. Core compute regions are Akamai core data centers that offer the full set or majority of our cloud computing services. They're designed with scale in mind and are ideal for larger production workloads or applications.
- Distributed compute region, also referred to as a distributed location. Distributed compute regions offer limited computing services in underrepresented geographic areas. You can set up a Linode in these regions, so you can target them to create a custom image. Check out our detailed, Akamai Cloud map.
Distributed compute regions is Limited Availability. You need distributed compute region support on your account to maintain Linodes in a distributed compute region.
To learn more about regions, see Regions and images.
Regions and images
When you create a new image, it’s stored in a specific compute region, using our Object Storage application. We offer multiple region types to best administer your Linodes. Review these sections to understand how regions can apply to your images.
Regions and captured custom images
You capture an image from an existing Linode and we store that image using our Object Storage service. There are two scenarios where regions can affect how you capture:
-
The Linode is in a core compute region that supports Object Storage. Here, the image is captured and stored in that same region.
-
The Linode is in a compute region that doesn't support Object Storage. This can be a core compute region that doesn’t currently support Object Storage or a distributed compute region that offers limited services. In both cases, the image is captured and stored in a core region that supports Object Storage and is geographically closest.
Regardless of where an image is stored, you can deploy it to a new or existing Linode in any region.
North America
| Where the image was captured | Where the image is stored |
|---|---|
| US - Dallas, TX (us-central)* | US - Chicago, IL (us-ord) |
| US - Denver, CO | US - Chicago, IL (us-ord) |
| US - Fremont, CA (us-west)* | US - Los Angeles, CA (us-lax) |
| US - Houston, TX | US - Chicago, IL (us-ord) |
| CA - Toronto, ON (ca-central)* | US - Chicago, IL (us-ord) |
| MX - Querétaro | US - Los Angeles, CA (us-lax) |
* Core compute region that doesn't currently support Object Storage.
Africa
| Where the image was captured | Where the image is stored |
|---|---|
| ZA - Johannesburg | FR, Paris (fr-par) |
Asia
| Where the image was captured | Where the image is stored |
|---|---|
| IN, Mumbai (ap-west) | IN, Chennai (in-maa) |
| IN, Mumbai 2 (in-bom-2) | IN, Chennai (in-maa) |
| JP, Tokyo 2 (ap-northeast)* | JP, Osaka (jp-osa) |
| JP, Tokyo 3 (jp-tyo-3)* | JP, Osaka (jp-osa) |
| MY, Kuala Lumpur | SG, Singapore (ap-south) |
| SG, Singapore 2 (sg-sin-2)* | SG, Singapore (ap-south) |
* Core compute region that doesn't currently support Object Storage.
Europe
| Where the image was captured | Where the image is stored |
|---|---|
| DE, Frankfurt 2 (de-fra-2)* | NL, Amsterdam (nl-ams) |
| DE, Hamburg | DE, Frankfurt (eu-central) |
| FR, Marseilles | FR, Paris (fr-par) |
| GB, London (eu-west)* | SE, Stockholm (se-sto) |
| GB, London 2 (gb-lon)* | SE, Stockholm (se-sto) |
* Core compute region that doesn't currently support Object Storage.
Oceania
| US - Dallas, TX (us-central)* | US - Chicago, IL (us-ord) |
|---|---|
| AU, Melbourne (au-mel)* | ID, Jakarta (id-cgk) |
| AU, Sydney (ap-southeast)* | IN, Chennai (id-maa) |
* Core compute region that doesn't currently support Object Storage.
South America
| Where the image was captured | Where the image is stored |
|---|---|
| CO, Bogotá | BR, Sao Paulo (br-gru) |
| CL, Santiago | BR, Sao Paulo (br-gru) |
Regions and uploaded custom images
When you upload a new custom image, you select a specific core region where you want it stored. Only core compute regions that support our Object Storage service can be used to store an uploaded image.
You can't upload an image to a distributed compute region.
Regions and recovery images
A recovery image can be automatically created when you delete a disk from a Linode. They’re stored as follows:
- Core compute region. The recovery image is stored in the same core region where its deleted Linode was located. Recovery images are not stored using our Object Storage service, so Object Storage availability in a core region doesn't apply.
- Distributed compute region. Recovery images are not currently supported for Linodes in distributed compute regions.
If you delete a disk on a Linode in a distributed compute region, a recovery image is not generated. Ensure you want to delete a disk before you complete the operation.
Deploy an image to a region
You can deploy a custom or recovery image to any compute region you have access to. This includes both core compute regions or distributed compute regions.
Region support matrix
| Task | Core region w/ Object Storage | Core region w/out Object Storage | Distributed region |
|---|---|---|---|
| Capture a custom image | Yes. | Yes. | Yes. |
| Store a captured image | Yes. The captured image is stored in the same core region where it was taken. | No. The captured image is stored in the core region that supports Object Storage, and is geographically closest. | No. The captured image is stored in the core region that supports Object Storage, and is geographically closest. |
| Upload a custom image | Yes. You pick a specific core region where you want to store the image. | No. You can't store an uploaded image in a core region that doesn't support Object Storage. (These regions aren't available for selection when uploading an image.) | No. You can't upload a custom image to a distributed region. |
| Save a recovery image | Yes. This happens automatically when a Linode is deleted from a core region. | Yes. This happens automatically when a Linode is deleted from a core region. | No. Distributed regions don't support recovery images. |
| Store a recovery image | Yes. The recovery image is stored in the same core region where it was deleted. Recovery images don't use Object Storage. | Yes. The recovery image is stored in the same core region where it was deleted. Recovery images don't use Object Storage. | No. Distributed regions don't support recovery images. |
| Deploy an image | Yes. You can deploy a stored image to any core region. | Yes. You can deploy a stored image to any core region. | Yes. You can deploy a stored image to any Distributed region. |
Pricing
- Custom images. To check the pricing details, see Akamai Cloud Predictable Pricing.
- Recovery images. They're provided at no charge, but instances deployed from recovery images are billed according to your contract.
- Shared images. Sharing an image is free of charge, but instances deployed from shared images are billed according to your contract.
Developer resources
Linode API
The Linode API v4 lets you programmatically manage the full range of our products and services. See the available Linode API for Images.
Linode CLI
The Linode CLI is a wrapper around the Linode API v4 that allows you to manage your account and resources from the command line. Learn how to use and install the Linode CLI to get started.
Updated about 1 month ago