Kubernetes Deployment Options
When deploying Kasm Workspaces on Kubernetes, the Helm chart covers the core services but not everything. Which additional components you need to provision depends on what session types you want to support and how many zones you are running.
Service Roles
Kasm Workspaces is composed of four service roles. Each role can be deployed independently, and larger deployments typically spread them across separate hosts for performance and isolation.
App
Includes: NGINX, API, Manager
The App role is the control plane for a zone. It handles authentication, session orchestration, and all administrative UI and API functions. Every zone requires exactly one App instance. The App role should be deployed close to the database, as it is the only role that communicates directly with it.
Connection Proxy
Includes: NGINX, Guacamole, RDP Gateway, RDP HTTPS Gateway
The Connection Proxy role routes browser-based RDP, VNC, and SSH connections to external workloads. It is the gateway for any non-Docker session type. For best performance it should be deployed close to the target workloads (Windows VMs, Linux RDP hosts, etc.) it proxies.
Dedicated Proxy
Includes: NGINX (kasm_proxy)
The Dedicated Proxy role is a standalone zone-local relay that directs end-users to the correct Kasm Agent for container sessions. Rather than routing KasmVNC session traffic through the App role, a Dedicated Proxy handles that routing locally within the zone, reducing latency.
In standard deployments, session routing for container sessions is handled by the built-in proxy in the App role — no Dedicated Proxy is needed. The standalone Dedicated Proxy (--role proxy) is an alternative to that built-in routing, providing a zone-local relay. It is most beneficial when an additional zone is geographically distant from the primary zone.
Agent
Includes: Docker runtime, Kasm Agent service, kasm_proxy
The Agent role runs containerized desktop and application sessions. Each Agent also runs a local kasm_proxy for routing its own sessions. Agents are always deployed outside of Kubernetes on standard Docker hosts and are never included in the Helm chart. Each zone needs its own Agent pool — Agents are not shared across zones.
What the Helm Chart Deploys
Single-Zone Deployment
The Helm chart bundles the App, Connection Proxy, and Dedicated Proxy roles into the cluster. This covers all session routing for the primary zone out of the box.
| Role | Deployed by Helm | Notes |
|---|---|---|
| App | Yes | API, Manager, built-in PostgreSQL |
| Connection Proxy | Yes | Guacamole, RDP Gateway, RDP HTTPS Gateway |
| Dedicated Proxy | Yes | Proxies KasmVNC traffic to Agents |
| Agent | No | Must be provisioned separately |
To support container sessions in a single-zone deployment, you only need to add Agents. RDP and VNC sessions work immediately via the bundled Connection Proxy.
Multi-Zone Deployment
When you define multiple zones in my-values.yaml, the Helm chart deploys the full set of roles for the primary zone (first in the list) but only the App role for each additional zone. Proxy and Agent components for additional zones must be provisioned externally via the multi-server installation guide.
| Role | Primary Zone | Additional Zones |
|---|---|---|
| App | Helm (in cluster) | Helm (in cluster, one per zone) |
| Connection Proxy | Helm (in cluster) | External — deploy if supporting RDP/VNC |
| Dedicated Proxy | Helm (in cluster) | External — deploy for container session performance |
| Agent | External | External — deploy if supporting container sessions |
Choosing What to Deploy
Use the table below to determine which external components to provision for each additional zone. The primary zone requires no external components unless you are adding Agents.
| Container sessions | RDP / VNC sessions | External components needed (per additional zone) |
|---|---|---|
| No | No | None |
| Yes | No | Agent; Dedicated Proxy (optional — reduces latency) |
| No | Yes | Connection Proxy |
| Yes | Yes | Agent, Connection Proxy; Dedicated Proxy (optional — reduces latency) |
Agents are required for any zone that runs container sessions, including the primary zone. The Dedicated Proxy is optional: without it, container session traffic routes through the App role's built-in proxy rather than a zone-local relay — sessions work, but potentially with higher latency. A Dedicated Proxy is most beneficial when additional zones are geographically distant from the primary zone.
Related Resources
- Install Kasm on Kubernetes — step-by-step Helm installation
- Multi-Zone Proxies with Kubernetes — provision Connection and Dedicated Proxies for additional zones
- Multi-Server Installation Guide — install individual roles on external VMs
- Connection Proxies — deeper explanation of how the Connection Proxy role works