Create custom images
Stay organized with collections
Save and categorize content based on your preferences.
Linux
You can create custom images from source disks, images, snapshots, or images
stored in Cloud Storage and use these images to create virtual machine (VM)
instances. Custom images are ideal for situations where you have created and
modified a persistent boot disk or specific image to a certain state and need to
save that state for creating VMs.
Alternatively, you can use the virtual disk import
tool to import boot disk images
to Compute Engine from your existing systems and add them to your custom
images list.
If you haven't already, set up authentication.
Authentication verifies your identity for access to Google Cloud services and APIs. To run
code or samples from a local development environment, you can authenticate to
Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and
APIs, you don't need to set up authentication.
gcloud
Install the Google Cloud CLI.
After installation,
initialize the Google Cloud CLI by running the following command:
To use the Go samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
To use the Java samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
To use the Node.js samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
To use the Python samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
These predefined roles contain
the permissions required to create a custom image. To see the exact permissions that are
required, expand the Required permissions section:
Required permissions
The following permissions are required to create a custom image:
compute.images.create
To create a custom image from a disk:
compute.disks.useReadOnly
on the disk
iam.serviceAccounts.actAs
on the instance's service account, if the disk is the boot disk of an instance that has an attached service account
To create a custom image from an existing image:
compute.images.useReadOnly
on the source image
To create a custom image from a standard or archive snapshot:
compute.snapshots.useReadOnly
on the source snapshot
To add a label to the new image:
compute.images.setLabels
on the label
This section describes how to create a custom image on a Linux VM. For
information about creating a Windows image, see Creating a Windows
image.
Select an image storage location
When creating a custom image, you can specify the image's
Cloud Storage location, excluding dual-region
locations. By specifying the image storage location, you can meet your
regulatory and compliance requirements for data locality as well as your high
availability needs by providing redundancy across regions. To create, modify,
and delete images stored in Cloud Storage, you must have
roles/compute.storageAdmin.
The storage location feature is optional. If you don't select a location,
Compute Engine stores your image in the multi-region closest to the
image source. For example, when you create an image from a source disk that is
located in us-central1 and if you don't specify a location for the custom
image, then Compute Engine stores the image in the us multi-region.
If the image is not available in a region where you are creating a
VM, Compute Engine caches the image in that region the first time you
create a VM.
To see the location where an image is stored, use the
images describe
command from gcloud compute:
PROJECT_ID: the project ID to which the image belongs.
All of your existing images prior to this feature launch remain where they are,
the only change is that you can view the image location of all your images. If
you have an existing image you want to move, you must recreate it in the new
location.
Prepare your VM for an image
You can create an image from a disk even while it is attached to a running
VM. However, your image is more reliable if you put the VM
in a state that is easier for the image to capture. This section describes how
to prepare your boot disk for the image.
Minimize writing data to the persistent disk
Use one of the following processes to reduce the disk writes:
Stop the VM
so that it can shut down and stop writing any data to the persistent disk.
If you can't stop your VM before you create the image, minimize the
amount of writes to the disk and sync your file system. To minimize
writing to your persistent disk, follow these steps:
Pause apps or operating system processes that write data to
that persistent disk.
Run an app flush to disk if necessary. For example, MySQL has a
FLUSH
statement. Other apps might have similar processes.
Stop your apps from writing to your persistent disk.
Run sudo sync.
Disable the auto-delete option for the disk
By default, the auto-delete option is enabled on the boot disks. Before creating
an image from a disk, disable auto-delete to prevent the disk from being
automatically deleted when you delete the VM.
To disable auto-delete for the disk, use one of the following methods:
You can create a disk image once every 10 minutes. If you want to issue
a burst of requests to create a disk image, you can issue at most 6 requests
in 60 minutes. For more information, see
Snapshot frequency limits.
Use guest operating system (OS) features to configure the following networking,
security, storage, and OS options on custom images. Custom images
with these configured features are used as boot disks.
Unified Extensible Firmware Interface (UEFI) variables are key-value pair variables
used by the UEFI firmware during boot time to boot the operating system of a VM.
Unlike physical machines, where the variables are stored on a hardware chip,
Compute Engine virtualizes storage of these variables. As such, in
many operating systems, all applications and users can reach these variables and
access this information.
Because of this reason, Google strongly recommends that you don't write or store
sensitive or personal identifiable information such as passwords or private keys
to UEFI variables.
Considerations for Arm images
Google offers the A4X, C4A, and Tau T2A
machine series, which run on Arm CPU platforms. You can start a VM with one of
these machine series and then use that source VM to create an Arm image. The
process for creating a custom Arm image is identical to creating an x86 image.
To help your users differentiate between Arm and x86 images, Arm images will
have an architecture field set to ARM64. Possible values for this
field are:
ARCHITECTURE_UNSPECIFIED
X86_64
ARM64
Image users can then filter on this field to find x86 or Arm-based images.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-12 UTC."],[],[]]