Stay organized with collections
Save and categorize content based on your preferences.
When you create a repository, you must specify its location. The
chosen location determines where the repository storage is created. You can
create repositories in the following types of locations:
Region is a specific geographic place, such as Tokyo or Northern Virginia.
Multi-region is a large geographic area, such as Asia or the
United States, that contains two or more geographic places.
Artifact Registry stores artifacts in the selected location in
accordance with the Service Specific Terms.
A good location balances latency, availability, and bandwidth costs for data
consumers.
Use a region to help optimize latency and network bandwidth for uploads
and downloads by systems located in the same region.
Use a multi-region when you want to interact with systems that are
outside of the Google network and distributed across large geographic areas,
or when you want the higher availability that comes with being
redundant across regions.
Generally, you should store your artifacts in a location that is convenient or
contains the majority of the users of your data.
While you can't specify a Compute Engine zone repository location,
all Compute Engine VM instances in zones within a given region
have similar performance when accessing storage in that region.
To view a list of supported repository locations, run the command:
gcloudartifactslocationslist
Location constraints
Your organization might have specific requirements for the location of
stored data. If your organization policy includes
resource location constraints,
Artifact Registry enforces the constraints when you create a repository.
Organization policy compliance isn't enforced retroactively on existing
repositories. To enforce new location constraints on existing stored artifacts,
create new repositories after the organization policy is applied, and then
migrate artifacts from old repositories to the new ones. You can use the gcrane
tool to copy images between repositories.
Available regions
Continent
Region Name
Region Description
North America
northamerica-northeast1
Montréal
northamerica-northeast2
Toronto
northamerica-south1
Queretaro
us-central1
Iowa
us-east1
South Carolina
us-east4
Northern Virginia
us-east5
Columbus
us-south1
Dallas
us-west1
Oregon
us-west2
Los Angeles
us-west3
Salt Lake City
us-west4
Las Vegas
South America
southamerica-east1
São Paulo
southamerica-west1
Santiago
Europe
europe-central2
Warsaw
europe-north1
Finland
europe-north2
Stockholm
europe-southwest1
Madrid
europe-west1
Belgium
europe-west2
London
europe-west3
Frankfurt
europe-west4
Netherlands
europe-west6
Zürich
europe-west8
Milan
europe-west9
Paris
europe-west10
Berlin
europe-west12
Turin
Middle East
me-central1
Doha
me-central2
Dammam
me-west1
Tel Aviv
Asia
asia-east1
Taiwan
asia-east2
Hong Kong
asia-northeast1
Tokyo
asia-northeast2
Osaka
asia-northeast3
Seoul
asia-south1
Mumbai
asia-south2
Delhi
asia-southeast1
Singapore
asia-southeast2
Jakarta
Australia
australia-southeast1
Sydney
australia-southeast2
Melbourne
Africa
africa-south1
Johannesburg
Available multi-regions
A multi-regional location's data centers are spread across a general
geographical area. For example, a resource created in the europe multi-region
persists in multiple data centers within the European Union. It is not possible
to configure which data centers are selected or where they are located within
the multi-region.
If you use Google Kubernetes Engine Image streaming, your Artifact Registry
repository must be in the same region as your GKE
nodes, or in a multi-region that corresponds with the region where your nodes
are running. For example:
If your nodes are in us-east1, Image streaming is available for
repositories in the us-east1 region or the us multi-region since both
GKE and Artifact Registry are running in data center locations within
the United States.
If your nodes are in the northamerica-northeast1 region, the nodes are
running in Canada. In this situation, Image streaming is only available
for repositories in the same region.
Multi-Region Name
Multi-Region Description
asia
Data centers in Asia
europe
Data centers in the European Union1
us
Data centers in the United States
1 Object data added to a repository in the europe multi-region
is not stored in the europe-west2 or europe-west6 data center.
[[["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 2025-08-29 UTC."],[[["\u003cp\u003eRepositories in Artifact Registry must be assigned a location, which can be either a specific region, like Tokyo, or a multi-region, such as Asia.\u003c/p\u003e\n"],["\u003cp\u003eChoosing a region helps optimize latency and network bandwidth for systems located in that same region, while multi-regions are better for interactions with systems outside the Google network or requiring high availability.\u003c/p\u003e\n"],["\u003cp\u003eStoring artifacts in the same region as Compute Engine VM instances can enhance performance, and while a specific zone cannot be selected for a repository, VMs within the same region will experience similar performance.\u003c/p\u003e\n"],["\u003cp\u003eOrganization policies may enforce location constraints on repositories, and if existing repositories need to adhere to these new constraints, new repositories must be created and artifacts migrated to them.\u003c/p\u003e\n"],["\u003cp\u003eMulti-regions include the geographic areas of \u003ccode\u003easia\u003c/code\u003e, \u003ccode\u003eeurope\u003c/code\u003e, and \u003ccode\u003eus\u003c/code\u003e, and when using Image streaming with Google Kubernetes Engine, the repository must be in the same region as the GKE nodes, or a multi-region corresponding to the nodes' region.\u003c/p\u003e\n"]]],[],null,["# Artifact Registry locations\n\nWhen you create a repository, you must specify its location. The\nchosen location determines where the repository storage is created. You can\ncreate repositories in the following types of locations:\n\n- *Region* is a specific geographic place, such as Tokyo or Northern Virginia.\n\n- *Multi-region* is a large geographic area, such as Asia or the\n United States, that contains two or more geographic places.\n\nArtifact Registry stores artifacts in the selected location in\naccordance with the [Service Specific Terms](/terms/service-terms).\n\nA good location balances latency, availability, and bandwidth costs for data\nconsumers.\n\n- Use a region to help optimize latency and network bandwidth for uploads and downloads by systems located in the same region.\n\n\u003c!-- --\u003e\n\n- Use a multi-region when you want to interact with systems that are outside of the Google network and distributed across large geographic areas, or when you want the higher availability that comes with being [redundant across regions](/storage/docs/availability-durability#cross-region-redundancy).\n\n\u003c!-- --\u003e\n\n- Generally, you should store your artifacts in a location that is convenient or\n contains the majority of the users of your data.\n\n- For Compute Engine\n\n - Storing data in the same region as your [Compute Engine VM instances](/compute/docs/instances) can provide better performance.\n - While you can't specify a Compute Engine zone repository location, all Compute Engine VM instances in zones within a given region have similar performance when accessing storage in that region.\n\nTo view a list of supported repository locations, run the command: \n\n gcloud artifacts locations list\n\nLocation constraints\n--------------------\n\nYour organization might have specific requirements for the location of\nstored data. If your organization policy includes\n[resource location constraints](/resource-manager/docs/organization-policy/defining-locations),\nArtifact Registry enforces the constraints when you create a repository.\n\nOrganization policy compliance isn't enforced retroactively on existing\nrepositories. To enforce new location constraints on existing stored artifacts,\ncreate new repositories after the organization policy is applied, and then\nmigrate artifacts from old repositories to the new ones. You can use the [gcrane](https://github.com/google/go-containerregistry/tree/main/cmd/gcrane)\ntool to copy images between repositories.\n\nAvailable regions\n-----------------\n\nAvailable multi-regions\n-----------------------\n\nA multi-regional location's data centers are spread across a general\ngeographical area. For example, a resource created in the `europe` multi-region\npersists in multiple data centers within the European Union. It is not possible\nto configure which data centers are selected or where they are located within\nthe multi-region.\n\nIf you use Google Kubernetes Engine [Image streaming](/kubernetes-engine/docs/how-to/image-streaming), your Artifact Registry\nrepository must be in the same [region](#location-r) as your GKE\nnodes, or in a multi-region that corresponds with the region where your nodes\nare running. For example:\n\n- If your nodes are in `us-east1`, Image streaming is available for repositories in the `us-east1` region or the `us` multi-region since both GKE and Artifact Registry are running in data center locations within the United States.\n- If your nodes are in the `northamerica-northeast1` region, the nodes are running in Canada. In this situation, Image streaming is only available for repositories in the same region.\n\n^1^ Object data added to a repository in the `europe` multi-region\nis not stored in the `europe-west2` or `europe-west6` data center.\n\nWhat's next\n-----------\n\n- [Create repositories](/artifact-registry/docs/repositories/create-repos)\n- [Learn more about location concepts](/docs/geography-and-regions)"]]