SaaS Runtime locations
Stay organized with collections Save and categorize content based on your preferences.

Regions

SaaS Runtime is available in the following regions. For more information about regions and zones, see Geography and regions.

Asia Pacific

The following table lists the available regions in Asia Pacific.

Region description	Region name
Tokyo	`asia-northeast1`
Osaka	`asia-northeast2`
Seoul	`asia-northeast3`
Taiwan	`asia-east1`
Hong Kong	`asia-east2`
Mumbai	`asia-south1`
Delhi	`asia-south2`
Singapore	`asia-southeast1`
Jakarta	`asia-southeast2`
Sydney	`australia-southeast1`
Melbourne	`australia-southeast2`

Europe

The following table lists the available regions in Europe.

Region description	Region name
Finland	`europe-north1`
Poland	`europe-central2`
Belgium	`europe-west1`
United Kingdom	`europe-west2`
Germany	`europe-west3`
Netherlands	`europe-west4`
Switzerland	`europe-west6`

Americas

The following table lists the available regions in the Americas.

Region description	Region name
South Carolina	`us-east1`
Virginia	`us-east4`
Oregon	`us-west1`
California	`us-west2`
Utah	`us-west3`
Nevada	`us-west4`
Iowa	`us-central1`
Montréal	`northamerica-northeast1`
Toronto	`northamerica-northeast2`
São Paulo	`southamerica-east1`
Santiago	`southamerica-west1`

The `saas.locations` field

The saas.locations field, within the SaaS offering resource, defines where your SaaS Runtime units can reside, and how your rollouts are managed. The saas.locations field serves as a single source of truth for the supported regions of your SaaS offering.

Rollout regionalization considerations

Supported locations for rollouts are determined by the top-level regions defined in your SaaS offering's supported regions (saas.locations).

Rollouts read the list of supported regions directly from the associated SaaS offering's saas.locations field.

Resource replication

When you create SaaS Runtime resources like releases and unit kinds, they are propagated across all of the regions specified in the saas.locations field of your SaaS offering, in addition to the global region. This replication ensures consistency and availability across your supported regions.

For more information about observability into resource replication, see Monitor your SaaS offering.

Resource replication using the CLI or API

If you are creating SaaS Runtime resources (for example, a release, unit kind, or SaaS offering) using the CLI or API, you are responsible for creating these resources in global, and in each of the regions listed in saas.locations.

For example, if saas.locations is set to ['us-central1', 'eu-west1'], SaaS Runtime will create three SaaS offering resources:

One in global (with .location = 'global')
One in us-central1 (with .location = 'us-central1')
One in eu-west1 (with .location = 'eu-west1')

All three SaaS offering resources will have the same .locations field (['us-central1','eu-west1']). SaaS Runtime likewise would create unit kinds and releases in global, us-central1, and eu-west1.

You can use global for orchestration, but avoid listing global as a deployment target within the saas.locations field.

Handling edits to the saas.locations field or other resources that are replicated across regions is limited. You need to manually apply edits to each replicated resource.

Artifact Registry and Developer Connect locations

The locations of your Artifact Registry repository and Developer Connect instance have specific requirements:

The region of your Artifact Registry repository and Developer Connect instance can be any valid Google Cloud region. They don't need to be included in saas.locations.
The region of your Artifact Registry repository must match the region of your Developer Connect instance.
During unit provisioning, SaaS Runtime copies the artifact from your Artifact Registry repository to the region where the unit is being deployed.

This necessitates the presence of SaaS offering, release, and unit kind resources in all regions listed in saas.locations, even though the Artifact Registry and Developer Connect reside in a single (potentially different) region.
Units can only be created in regions specified in the saas.locations field. Units aren't propagated to global unless explicitly specified and it's not recommended to do so.

Example SaaS Runtime regions configuration

We have provided this example to demonstrate how regionalization works when using SaaS Runtime.

For example, if you wanted to deploy your SaaS offering in us-central1 and europe-west4, while hosting your Artifact Registry repository and Developer Connect instance in us-east1, your SaaS Runtime regions infrastructure would be something like:

saas.locations: ['us-central1', 'europe-west4']
Artifact Registry repository region: us-east1
Developer Connect instance region: us-east1
SaaS offering, unit kind, and release resources: Created by SaaS Runtime in global, us-central1, and europe-west4 using SaaS Runtime in Google Cloud console.

Note: If you are using SaaS Runtime through the API or CLI, you are responsible for creating SaaS offering, unit kind, and release in each region.
Units: Units could be created in either us-central11, or europe-west4.

This configuration lets you manage your deployments across two regions while keeping your artifact management centralized in a third, distinct region. You should consider your latency, compliance, and data residency requirements carefully when selecting your regions.