Understanding Deployment Zones
Architects encountering Kasm Workspaces Deployment Zones for the first time often treat zone configuration as a late-stage administrative task, something to revisit after the platform is running. That approach leads to a predictable class of problems, sessions routing to the wrong geographic tier, RDP connections failing through firewalls, cookie-scoped authentication breaking in portal integrations, and load balancing decisions that work against user experience rather than for it.
Zones are not an administrative overlay. They are the mechanism through which Kasm's control plane and session plane separation is expressed in a global deployment. Every zone setting is a direct statement about how those two planes relate to each other and to the users they serve.
What a Zone Actually Represents
A Zone is a logical boundary that groups Kasm services sharing a common network context. That context might be geographic, organizational, or regulatory. The zone mechanism is neutral about which concern drives its definition, but it is not neutral about the architectural implications that follow.
| Zone Use Case | Zone Purpose |
|---|---|
| Geographic distribution | Route users to Agents closer to them for lower latency |
| Security enclave separation | Isolate workloads by classification level or tenant |
| Network segment isolation | Scope sessions to permitted egress paths per segment |
| Workspace restriction | Limit which workspace types are available in which network |
Zones are created at Web App installation time and the zone topology must be understood and planned, not improvised after the platform is in production.
The Zone Settings: What Each One Actually Governs
Zone settings are primarily concerned with the session plane. Zone configuration is how the session plane is told where it actually lives from the perspective of the client browser. The distinction between where infrastructure physically lives and where the browser thinks it lives is the source of most zone misconfiguration in enterprise deployments.
Zone Name and Zone Assignment
The Zone Name setting carries structural weight beyond its appearance as a simple text label. Every Web App service instance declares its zone membership through its configuration. Every Kasm node that checks in with a Manager inherits that Manager's zone assignment automatically.
Labels extend zone assignment with fine-grained targeting. Labels are key-value tags applied to servers and Agents within a zone. Workspaces specify Include Labels or Exclude Labels to control which infrastructure their sessions are permitted to use. This is the primary mechanism for workspace-to-enclave binding, ensuring that high-sensitivity workspaces only provision on Agents within a specific zone regardless of what capacity other zones have available.
Search Alternate Zones: Availability vs. Isolation
Search Alternate Zones governs what happens when all Agents within the user's current zone are full or unavailable. The decision to enable or disable this setting is a policy question, not a technical one.
When zones represent geographic regions: enabling is almost always correct. A user whose nearest data center is temporarily at capacity should receive a slightly higher-latency session from an alternate zone rather than a hard failure.
When zones represent security enclaves or regulatory boundaries: disabling may be architecturally mandatory. If a zone represents a PCI-scoped network segment, allowing session overflow into a general-purpose zone would be a compliance violation. The failure mode, a capacity error, is the correct behavior when the alternative is a boundary violation.
The default is Enabled, which encodes an implicit assumption that zones are geographic, not regulatory. Organizations deploying zones for compliance or tenant isolation should consciously evaluate whether this default aligns with their security policy before going to production.
Prioritize Static Agents: Managing Hybrid Compute Pools
Prioritize Static Agents governs how the Manager selects between manually registered agents and dynamically provisioned autoscaled agents when both are available in the same zone.
Enabling it ensures sunk-cost on-premises infrastructure is consumed before variable-cost cloud infrastructure is activated. This is financially rational in most hybrid deployments. Disabling it may be appropriate only when cloud Agents have superior performance characteristics that justify preferential use.
Proxy Hostname: The Most Consequential Zone Setting
Proxy Hostname is the FQDN that Kasm embeds in the session connection URL and returns to the client's browser. It is the address the browser will actually attempt to connect to for WebSocket session traffic. This is the single most consequential zone setting for multi-tier deployments.
The default value $request_host$ evaluates to the hostname used when the user accessed the Kasm Web App. For single-region deployments where the Web App and Proxy are behind the same load balancer on the same hostname, this default works correctly. For multi-region deployments with separate proxy tiers per zone, this value must be explicitly overridden with the zone-specific proxy FQDN.
Leaving Proxy Hostname at its default $request_host$ in a multi-zone deployment is one of the most common causes of session delivery failures in enterprise deployments. The browser will attempt to connect to the Web App's hostname for session streaming rather than the zone-specific proxy hostname. The failure appears as a session connectivity problem rather than a configuration problem, which misleads diagnostic efforts.
Upstream Auth Address: The Control Plane's View of Itself
Upstream Auth Address is the address Kasm uses to validate session authentication tokens. The default value proxy instructs the proxy to validate tokens against a co-located API server, correct for single-server deployments. In any distributed deployment, this value must be overridden with the address of the Web App tier.
Setting the Upstream Auth Address to the internal IP of a single Web App server in a multi-server HA deployment is a common mistake. If that specific server is removed from the pool, proxy token validation fails even though the overall Web App tier remains healthy. The correct value in HA deployments is the load balancer's FQDN, so that token validation requests are distributed across all healthy Web App instances.
Allow Origin Domain: The CORS Security Boundary
Allow Origin Domain enforces which origins are permitted to initiate WebSocket session connections to Kasm. This implements browser-level CORS policy for session traffic, preventing session tokens from being usable from unauthorized web origins.
The default value $request_host$ is correct for straightforward deployments. When the Web App and the session proxy are on different hostnames, this default produces CORS failures because the session connection is initiated from the Web App's hostname but the proxy evaluates the origin against its own hostname.
In multi-hostname deployments, Allow Origin Domain must be set to the Web App's public hostname from which users actually initiate sessions.
The Three Settings That Must Be Mutually Consistent
The most important relationship in zone configuration is the one between Proxy Hostname, Upstream Auth Address, and Allow Origin Domain. All three must describe the same deployment from three different perspectives:
- Allow Origin Domain is what origin the proxy accepts session connection requests from
- Upstream Auth Address is what the proxy calls to validate the session token
- Proxy Hostname is what the client's browser connects to for session traffic
When these three are mutually consistent, sessions work. When any one is misaligned, the failure almost always appears as a session connectivity problem that looks deceptively like an authentication problem.
Zone Settings Quick Reference
| Setting | What It Governs | When to Override |
|---|---|---|
| Zone Name | Logical deployment boundary | When multiple regions, enclaves, or tenants exist |
| Allow Origin Domain | CORS security for session connections | When Web App and proxy are on different hostnames |
| Upstream Auth Address | Token validation target | Any multi-server deployment |
| Load Balance Strategy | Resource consumption policy | Cloud: change to Most Load |
| Search Alternate Zones | Overflow to other zones | Disable when zones are compliance or security boundaries |
| Prioritize Static Agents | Static vs. autoscale preference | Disable only when cloud Agents are preferred for performance |
| Proxy Hostname | Client-facing session plane address | Always in multi-zone and dedicated proxy deployments |
| Proxy Port | Session WebSocket port | When proxy listens on non-443 port |
| Enable RDP HTTPS Gateway | Port 443 vs. 3389 for RDP | Enable when clients connect from uncontrolled networks |
| Enable RDP HTTPS DLP | DLP enforcement on RDP sessions | Enable when Kasm must be the DLP enforcement point |
| Restrict RDP Client IP | Anti-replay for RDP sessions | Enable only when source IP is preserved end-to-end |
This article is part of the Kasm Workspaces Reference Architecture Explanation Series.