Deploy Secure Developer Spaces™ in multiple regions
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
- Copy the values from the primary deployment’s
platformsection. - Add a
regionsection and setisExternalRegiontotrue.
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
isExternalRegionis set totrue, setplatform.internalMongodbtofalse.
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.