Product documentation
Citrix Secure Developer Spaces™
View PDF

Deploy Secure Developer Spaces™ in multiple regions

October 10, 2025
Contributed by: 
C

This guide describes how to deploy Citrix Secure Developer Spaces™ across multiple Kubernetes clusters or regions. A multi-region setup improves developer experience by reducing latency and improving performance by routing users to the closest regional cluster.

Core concept

A multi-region deployment consists of:

  • Primary (central) deployment – Hosts the main database and services.
  • Regional deployments – Stateless deployments that connect to the primary deployment’s database and services.

To ensure seamless operation, critical configuration values (especially secrets for authentication and encryption) must be synchronized from the primary deployment to each regional deployment. This synchronization is done by copying specific values from the primary Helm deployment to the regional Helm chart.

How to deploy to additional regions

Like the primary deployment, regions are managed through Helm charts.

While the regional Helm charts are similar to those of the primary deployment, the main difference is that several values that are usually auto-generated during the first deployment must be manually copied from the primary deployment to the regional Helm charts.

These values include:

  • Database authentication credentials and connection parameters
  • Secrets for signing cookies and tokens
  • Secrets for encrypting stored values

Populate the Helm charts

  1. Copy the values from the primary deployment’s platform section.
  2. Add a region section and set isExternalRegion to true.

Example values.yaml:

platform:
  imageTag: ""                # Image tag for services
  hostName: ""                # Main domain used to access the platform, e.g. strong-network.example.com
  centralProxyHostname: ""    # Wildcard domain for workspaces, e.g. proxy.strong-network.example.com
  jwtSecret: ""               # Use the same jwtSecret as in the main deployment
  secretKeyReposB64: ""       # Example: openssl rand -base64 16
  # Include all other values from the primary deployment's platform section
  # ...
region:
  isExternalRegion: true      # For regional deployments, set this to true
<!--NeedCopy-->

Note:

When isExternalRegion is set to true, set platform.internalMongodb to false.

Required fields and their mappings

The following fields must match between the primary and regional deployments:

Field name Description
hostName Domain name of the deployment (used by users and API).
centralProxyHostname Workspace sub-domain of the main deployment (usually proxy.<hostName>)
jwtSecret Secret for signing tokens and cookies.
secretKeyReposB64 Secret for encrypting values.

Retrieve secrets from the primary deployment

Run the following commands in the namespace of the primary deployment cluster to extract the required values.

Get the hostName value

kubectl get secrets strong-network-secret -o yaml
<!--NeedCopy-->

Copy the hostName value from the output.

Get the secretKeyReposB64 value

kubectl get secrets strong-network-secret -o yaml
<!--NeedCopy-->

Copy the secretKeyReposB64 value, then base64 decode it before pasting it into the regional Helm charts.

For example:

echo "<base64-encoded-value>" | base64 --decode
<!--NeedCopy-->

Next steps

  • Verify that all required secrets and configuration values are synchronized between the primary and regional deployments.
  • Deploy the Helm chart for the regional cluster.
  • Confirm that developers can connect to the nearest regional deployment with minimal latency.
Deploy Secure Developer Spaces™ in multiple regions
October 10, 2025
Contributed by: 
C
October 10, 2025
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.