Google Private Service Connect Connectivity

Google Cloud Private Service Connect allows you to open a path to Temporal without opening a public egress. It establishes a private connection between your Google Virtual Private Cloud (VPC) and Temporal Cloud. This one-way connection means Temporal cannot establish a connection back to your service. This is useful if normally you block traffic egress as part of your security protocols. If you use a private environment that does not allow external connectivity, you will remain isolated.

Namespaces with High Availability features and GCP Private Service Connect

Automatic failover via Temporal Cloud DNS is not currently supported with GCP Private Service Connect. If you use GCP Private Service Connect, you must manually update your workers to point to the active region's Private Service Connect endpoint when a failover occurs.

Requirements

Your GCP Private Service Connect connection must be in the same region as your Temporal Cloud namespace. If using replication for High Availability, the PSC connection must be in the same region as one of the replicas.

Creating a Private Service Connect connection

Set up Private Service Connect with Temporal Cloud with these steps:

1. Open the Google Cloud console

2. Navigate to Network Services, then Private Service Connect. If you haven't used Network Services recently, you might have to find it by clicking on View All Products at the bottom of the left sidebar.

   

3. Go to the Endpoints section. Click on Connect endpoint.

   

4. Under Target, select Published service, this will change the contents of the form to allow you to fill the rest as described below

   

• For Target service, fill in the Service name with the Private Service Connect Service Name for the region you’re trying to connect to:

  Region	Private Service Connect Service Name
  asia-south1	projects/prod-d5spc2sfeshws33bg33vwdef7/regions/asia-south1/serviceAttachments/pl-7w7tw
  europe-west3	projects/prod-kwy7d4faxp6qgrgd9x94du36g/regions/europe-west3/serviceAttachments/pl-acgsh
  us-central1	projects/prod-d9ch6v2ybver8d2a8fyf7qru9/regions/us-central1/serviceAttachments/pl-5xzng
  us-east4	projects/prod-y399cvr9c2b43es2w3q3e4gvw/regions/us-east4/serviceAttachments/pl-8awsy
  us-west1	projects/prod-rbe76zxxzydz4cbdz2xt5b59q/regions/us-west1/serviceAttachments/pl-94w0x

• For Endpoint name, enter a unique identifier to use for this endpoint. It could be for instance temporal-api or temporal-api-<namespace> if you want a different endpoint per namespace.

• For Network and Subnetwork, choose the network and subnetwork where you want to publish your endpoint.

• For IP address, click the dropdown and select Create IP address to create an internal IP from your subnet dedicated to the endpoint. Select this IP.

• Check Enable global access if you intend to connect the endpoint to virtual machines outside of the selected region. We recommend regional connectivity instead of global access, as it can be better in terms of latency for your workers. Note: this requires the network routing mode to be set to GLOBAL.

5. Click the Add endpoint button at the bottom of the screen. If successful, the status of your new endpoint will appear as Accepted. Take note of the IP address that has been assigned to your endpoint, as it will be used to connect to Temporal Cloud.

6. You can now use GCP Private Service Connect. You can use the IP address of the previous step to connect to Temporal Cloud using port 7233. To establish a valid mTLS session, you must override the TLS server name used for the connection to <namespace>.<account>.tmprl.cloud.

tip

GCP Private Service Connect services are regional. Individual Namespaces do not use separate services.

Once set up, you can test your Private Service Connect connectivity using the following methods. When connecting, you must override the TLS server name to target your Namespace’s individual hostname (<namespace>.<account>.tmprl.cloud) to establish a valid mTLS session:

• The Temporal CLI, using the --tls-server-name parameter to override the TLS server name. For example:

  temporal workflow count \
      --address <IP address of the PSC endpoint>:7233 \
      --tls-cert-path /path/to/client.pem \
      --tls-key-path /path/to/client.key \
      --tls-server-name <namespace>.<account>.tmprl.cloud \
      --namespace <namespace>

• Non-Temporal tools like grpcURL, useful for testing from environments that restrict tool usage, using the -servername parameter to override the TLS server name. For example:

  grpcurl \
      -servername <name>.<account>.tmprl.cloud \
      -cert /path/to/client.pem \
      -key /path/to/client.key \
      <IP address of the PSC endpoint>:7233 \
      temporal.api.workflowservice.v1.WorkflowService/GetSystemInfo

• Temporal SDKs, by setting the endpoint server address argument to the Private Service Connect endpoint (<IP address of the PSC endpoint>:7233) and using the TLS configuration options to override the TLS server name.

When using API keys for namespace authentication, the TLS server name must be set to the Namespace's gRPC endpoint (<region>.<cloud_provider>.api.temporal.io) using one of the following methods:

• The Temporal CLI, using --tls-server-name parameter to override the TLS server name and the --tls flag to enforce the use of TLS. For example:

  temporal workflow count \
      --address <IP address of the PSC endpoint>:7233 \
      --namespace <namespace>.<account> \
      --api-key <api_key> \
      --tls-server-name <region>.<cloud_provider>.api.temporal.io \
      --tls

• Non-Temporal tools like grpcURL, setting the authorization and temporal-namespace headers, and the -servername parameter to override the TLS server name. For example:

  grpcurl \
      -H "authorization: Bearer <api_key>" \
      -H "temporal-namespace: <namespace>.<account>" \
      -servername <region>.<cloud_provider>.api.temporal.io \
      <IP address of the PSC endpoint>:7233 \
      temporal.api.workflowservice.v1.WorkflowService/GetSystemInfo

Configuring Private DNS for GCP Private Service Connect

Why configure private DNS?

When you connect to Temporal Cloud through GCP Private Service Connect you normally must:

1. Point your SDKs/Workers at the Private Service Connect endpoint IP address and
2. Override the Server Name Indicator (SNI) so that the TLS handshake still presents the public Temporal Cloud hostname (e.g., my-namespace.my-account.tmprl.cloud).

By creating a private Cloud DNS zone (PZ) that maps the public TemporalC Cloud hostname (or the region hostname) directly to the PSC endpoint IP address, you can:

• Keep using the standard Temporal Cloud hostnames in code and configuration.
• Eliminate the need to set a custom SNI override.
• Make future endpoint rotations transparent—only the DNS record changes.

This approach is optional; Temporal Cloud works without it, but it streamlines configuration and operations.

Prerequisites

Requirement	Notes
Google Cloud VPC Network with DNS enabled	PSC endpoints and the DNS zone must live in (or be attached to) the same network.
Private Service Connect endpoint for Temporal Cloud	Create an endpoint and reserve an internal IP in the namespace region
Cloud DNS API enabled and roles/dns.admin permissions	Needed to create private zones and records.
Namespace details	Determines which hostname pattern you override (table below).

Choose the override domain and endpoint

Temporal Cloud setup	Use this PHZ domain	Example
Single-region namespace with mTLS auth	<account>.tmprl.cloud	payments.abcde.tmprl.cloud ↔ X.X.X.X
Multi-region namespace or API-key auth	region.tmprl.cloud	aws-us-east-1.region.tmprl.cloud ↔ X.X.X.X

Step-by-step instructions

1. Collect your PSC endpoint IP address

# List the forwarding rule you created for the endpoint
gcloud compute forwarding-rules list \
  --filter="NAME:<endpoint-name>" \
  --format="value(IP_ADDRESS)"
# Example output: 10.1.2.3

Save the internal IP -- you will point the A record at it.

2. Create a Cloud DNS private zone

1. Open Network Services → Cloud DNS → Create zone.
2. Select zone type Private.
3. Enter a Zone name (e.g., temporal-cloud).
4. Enter a DNS name based on the table above (e.g., payments.abcde.tmprl.cloud or aws-us-east-1.region.tmprl.cloud).
5. Select Add networks and choose the Project and Network that contains your PSC endpoint.
6. Click Create.

3. Add an A record

Inside the new zone, add a standard A record:

Field	Value
DNS name	the namespace endpoint (e.g. payments.abcde.tmprl.cloud)
Resource record type	A
TTL	60s is typical, but you can adjust as needed.
IPv4 Address	the internal IP address of your PSC endpoint (e.g. 10.1.2.3)

4. Verify DNS resolution from inside the Network

dig payments.abcde.tmprl.cloud

If the hostname resolves to the PSC endpoint IP address from a VM in the bound network, the override is working.

Updating your workers/clients

With private DNS in place, configure your SDKs exactly as the public-internet examples show (filling in your own namespace):

clientOptions := client.Options{
    HostPort: "payments.abcde.tmprl.cloud:7233",
    Namespace: "payments",
    // No TLS SNI override needed
}

The DNS resolver inside your network returns the private endpoint IP address, while TLS still validates the original hostname—simplifying both code and certificate management.

Available GCP regions, PSC endpoints, and DNS record overrides

The following table lists the available Temporal regions, PrivateLink endpoints, and regional endpoints used for DNS record overrides:

North America - Iowa (us-central1)

• Cloud API Code: gcp-us-central1
• Regional Endpoint: gcp-us-central1.region.tmprl.cloud
• Private Service Connect Service Attachment URI: projects/prod-d9ch6v2ybver8d2a8fyf7qru9/regions/us-central1/serviceAttachments/pl-5xzng
• Same Region Replication: Not Available
• Multi-Region Replication:
  • gcp-us-west1
  • gcp-us-east4
• Multi-Cloud Replication:
  • aws-ca-central-1
  • aws-us-east-1
  • aws-us-east-2
  • aws-us-west-2

North America - Oregon (us-west1)

• Cloud API Code: gcp-us-west1
• Regional Endpoint: gcp-us-west1.region.tmprl.cloud
• Private Service Connect Service Attachment URI: projects/prod-rbe76zxxzydz4cbdz2xt5b59q/regions/us-west1/serviceAttachments/pl-94w0x
• Same Region Replication: Not Available
• Multi-Region Replication:
  • gcp-us-central1
  • gcp-us-east4
• Multi-Cloud Replication:
  • aws-ca-central-1
  • aws-us-east-1
  • aws-us-east-2
  • aws-us-west-2

North America - Northern Virginia (us-east4)

• Cloud API Code: gcp-us-east4
• Regional Endpoint: gcp-us-east4.region.tmprl.cloud
• Private Service Connect Service Attachment URI: projects/prod-y399cvr9c2b43es2w3q3e4gvw/regions/us-east4/serviceAttachments/pl-8awsy
• Same Region Replication: Not Available
• Multi-Region Replication:
  • gcp-us-central1
  • gcp-us-west1
• Multi-Cloud Replication:
  • aws-ca-central-1
  • aws-us-east-1
  • aws-us-east-2
  • aws-us-west-2

Europe - Frankfurt (europe-west3)

• Cloud API Code: gcp-europe-west3
• Regional Endpoint: gcp-europe-west3.region.tmprl.cloud
• Private Service Connect Service Attachment URI: projects/prod-kwy7d4faxp6qgrgd9x94du36g/regions/europe-west3/serviceAttachments/pl-acgsh
• Same Region Replication: Not Available
• Multi-Region Replication:
  • None
• Multi-Cloud Replication:
  • aws-eu-central-1
  • aws-eu-west-1
  • aws-eu-west-2

Asia Pacific - Mumbai (asia-south1)

• Cloud API Code: gcp-asia-south1
• Regional Endpoint: gcp-asia-south1.region.tmprl.cloud
• Private Service Connect Service Attachment URI: projects/prod-d5spc2sfeshws33bg33vwdef7/regions/asia-south1/serviceAttachments/pl-7w7tw
• Same Region Replication: Not Available
• Multi-Region Replication:
  • None
• Multi-Cloud Replication:
  • aws-ap-northeast-1
  • aws-ap-northeast-2
  • aws-ap-south-1
  • aws-ap-south-2
  • aws-ap-southeast-1
  • aws-ap-southeast-2