Planning and Design Concepts
About This Article
This series of explanation articles is written for Enterprise Architects evaluating or planning Kasm Workspaces deployments. Each article is understanding-oriented: the goal is to build a durable mental model of how and why the architecture is structured the way it is. These articles are not deployment guides, configuration references, or operational runbooks.
Zero Trust VDI Delivery for the Modern Enterprise
Architects arriving at Kasm Workspaces from a background in Citrix Virtual Apps and Desktops, Omnissa Horizon, Azure Virtual Desktop, or Amazon WorkSpaces carry deeply ingrained architectural instincts. Those instincts are valuable in their original context. They become actively misleading when applied to Kasm Workspaces.
The reason is not that Kasm is a variation of those platforms. It is that Kasm represents a fundamentally different delivery model, built on different assumptions, using different mechanisms, and optimized for a different world of threat conditions. Attempting to map familiar broker, connector, gateway, and hypervisor-pool patterns onto Kasm produces misaligned architecture decisions that are difficult to reverse once made.
The purpose of this article is to build the conceptual foundation that makes every subsequent architecture decision legible. Understanding why the platform was designed the way it was is more valuable than knowing how to configure any individual setting.
The Problem Kasm Was Built to Solve
Kasm Workspaces is not simply an incremental improvement to legacy VDI. It is not a thin‑client rebranding, nor is it simply VDI in containers. Instead, Kasm represents a fundamental rethinking of secure remote access and workspace delivery in a world where network perimeters have dissolved, users connect from any device on any network, and security threats such as malware and Advanced Persistent Threats (APTs) are sophisticated and ever evolving.
- HTTPS-based session delivery
- High-performance WebSocket streaming
- Browser-native authentication and access control
- All execution is performed in secure infrastructure, not on endpoints
- Pixel rendering is performed client-side in the browser
- No proprietary client software or endpoint agent required
Why Legacy VDI and VPN Models No Longer Scale
Traditional workspace delivery platforms were designed around assumptions that were reasonable when those platforms were conceived but have eroded substantially in most modern enterprises.
- Users connect from trusted networks or managed corporate endpoints
- Security enforcement occurs at the network perimeter
- VPN-based access is an acceptable mechanism for remote workers
Each of these assumptions breaks down in environments that must support hybrid workforces, third-party contractors, unmanaged devices, or sensitive data subject to Data Loss Prevention (DLP) requirements. VPN-based access extends the internal network directly to the endpoint, increasing the blast radius of any endpoint compromise and enabling lateral movement across the network. Legacy VDI reduces some risk, but still depends on proprietary client software, persistent desktops that accumulate state across sessions, and centralized trust models that treat network location as evidence of legitimacy.
Neither model was designed for a world where the network perimeter has dissolved and where a Zero Trust security strategy requires every access request to be individually validated regardless of its origin.
The Central Architectural Principle: Moving Work Off the Endpoint
The organizing principle behind Kasm Workspaces can be stated directly:
Workloads should execute in secure infrastructure environments, not on user devices.
This inverts the traditional model. In conventional VDI, the virtual machine is a full persistent environment running on infrastructure, and the client software on the endpoint renders its output. The endpoint is still a meaningful participant: it holds client certificates, runs proprietary protocol stacks, and may retain session data.
In Kasm Workspaces, the endpoint is a display device. Its role is limited to rendering a pixel stream delivered from infrastructure the organization controls. The endpoint never executes the application, never touches the underlying data directly, and never holds persistent session state when the session ends.
| Architectural Advantage | What It Means in Practice |
|---|---|
| Reduced endpoint attack surface | A compromised endpoint cannot compromise the workspace because execution occurs entirely in infrastructure |
| Isolation of untrusted content | Code, files, and browser activity run inside an ephemeral container that is destroyed at session end |
| Centralized execution control | Policy is enforced in infrastructure, not dependent on endpoint state or management enrollment |
| Elimination of persistent state | Sessions are disposable by design, removing the persistent foothold that Advanced Persistent Threats (APTs) rely on |
Web-Native Delivery
Web-native has a precise meaning in this context. It does not mean a product that happens to have a web interface layered on top of a proprietary protocol stack. It describes a delivery architecture where every component, from session origin to browser rendering, uses standard open web technologies with no proprietary protocol involved in the user-facing path.
When a user authenticates to Kasm Workspaces, the entire session lifecycle runs over HTTPS and WebSocket:
| Step | What Happens | Technology |
|---|---|---|
| 1 | User navigates to the Kasm URL in any modern browser | HTTPS |
| 2 | Browser authenticates against kasm_api via identity provider | HTTPS REST, SAML, or OIDC |
| 3 | kasm_manager schedules a container on an available Agent node | Internal API |
| 4 | Browser opens a WebSocket stream via kasm_proxy to the container | WebSocket over HTTPS |
| 5 | Session is rendered client-side inside the browser tab | HTML5 Canvas |
| 6 | Session ends; container is destroyed; no persistent state remains | Docker lifecycle |
The practical consequence of this architecture is significant: the complete user-facing firewall rule is a single outbound allow on port 443. There is no VPN client to install, no persistent tunnel to maintain, and no proprietary protocol handshake to traverse. The browser's native security sandbox becomes part of the session security boundary by design.
Note: The single-port constraint applies to traffic between end users and the Kasm platform. Internal component networking uses standard protocol ports: TCP 5432 for PostgreSQL, TCP 3389 for RDP to legacy targets, TCP 22 for SSH, and TCP 5900 for VNC. These are intra-infrastructure paths, not user-facing firewall requirements.
For legacy protocols such as RDP, VNC, and SSH, Kasm does not stream those protocols directly to the browser. The Connection Proxy role translates them server-side into a browser-renderable WebSocket stream before delivery. From the browser's perspective, all sessions arrive over the same HTTPS and WebSocket path.
Zero Trust Alignment: Architecture as Security Policy
Zero Trust is an architectural philosophy built on a single foundational assumption: breach is possible, and therefore containment is more important than prevention. Kasm Workspaces is designed at the architecture level to support the controls Zero Trust requires, rather than layering those controls on afterward.
| Zero Trust Control | How Kasm Implements It |
|---|---|
| Least Privilege Access | Users receive a session, not network access. Access is scoped to the specific workspace policy assigned to them |
| Micro-segmentation | Each session container has its own Linux kernel namespace. Sessions cannot communicate with each other at the network layer |
| Elimination of Implicit Trust | Each session is individually authenticated and authorized. There is no persistent authenticated tunnel that can be inherited across sessions |
| Attack Surface Reduction | The session container is destroyed on logout, removing all residual state. The browser sandbox is the outermost boundary |
| Embedded DLP | Clipboard access, file upload, and file download are configurable per workspace policy, enforced at the session boundary regardless of endpoint state |
In traditional VDI environments, DLP is layered on top of the system via endpoint agents, network inspection appliances, and after-the-fact monitoring. All of these approaches share a weakness: they depend on the endpoint and network being in a known, trusted state. In Kasm Workspaces, DLP is a property of how sessions are delivered, not an overlay. It applies uniformly across all device types, managed or unmanaged.
The Two Traffic Planes
One of the most consequential conceptual distinctions in Kasm Workspaces is the separation between two fundamentally different types of traffic. Every topology and placement decision in the reference architecture series traces back to understanding this separation.
| Characteristic | Control Plane | Session Plane |
|---|---|---|
| Content | Authentication, policy evaluation, session orchestration, workspace lifecycle | Live pixel stream, keyboard and mouse input, clipboard events, file transfer |
| Bandwidth profile | Low: primarily API call volume | High: approximately 5 to 15 Mbps per active session |
| Latency sensitivity | Database query latency: slow queries degrade launch times for all users simultaneously | Network round-trip between the proxy and the user's browser: high latency produces visible display lag |
| Database dependency | Yes: multiple sequential, blocking queries per operation | None: zero database interaction during an active session stream |
| Handled by | Web App role | Kasm Agent role or Connection Proxy role |
The two planes pull infrastructure in opposite directions in any distributed deployment:
- Control plane traffic anchors the Web App role to the vicinity of the database. Placing the Web App role far from the database introduces latency that degrades every user experience across every zone simultaneously.
- Session plane traffic benefits from proxy nodes placed as close as possible to end users. A Kasm Dedicated Proxy node can be placed in a geographically remote region with no control plane penalty, because it has zero database dependency.
This asymmetry is the architectural justification for the Dedicated Proxy role and the reason RA4 can support global geographic distribution without requiring a full control plane replica in every region.
The Five Service Roles and Their Responsibilities
Kasm Workspaces uses a role-based architecture. A role is a collection of services with a defined responsibility boundary. Roles can be co-located on a single server as in RA1, or distributed across many servers as in RA3 and RA4. The same role definitions apply regardless of co-location.
| Role | Key Services | Primary Port | Zone-Assigned | Database Dependency |
|---|---|---|---|---|
| Web App | kasm_api, kasm_manager, kasm_proxy | 443 | Yes | Critical |
| Database | kasm_db (PostgreSQL) | 5432 | No | N/A |
| Agent | kasm_agent, kasm_proxy, container runtime | 443 | Yes | None |
| Connection Proxy | kasm_guac, kasm_rdp_gateway, kasm_rdp_https_gateway, kasm_proxy | 22, 443, 3389, 5900 | Yes | None |
| Dedicated Proxy | kasm_proxy | 443 | Yes | None |
Understanding these roles as a system, rather than as individual services, is the key to reading any Kasm reference architecture diagram correctly.
The Deployment Patterns
Kasm architectures evolve through progressive separation of concerns. Each stage introduces greater resilience, greater scalability, and greater architectural clarity. The progression is not a forced upgrade path: each stage is appropriate for specific scale and fault-tolerance requirements.
| Architecture | DB Proximity | Zone Count | Fault Tolerance | Primary Use Case |
|---|---|---|---|---|
| RA1: Single Server | Automatic (same host) | 1 | None | POC, dev/test, small teams, edge sites |
| RA2: Single Server Control Plane + External Agents | Automatic (co-located) | 1 | Agent tier only | Capacity expansion, legacy access in remote networks |
| RA3: Single Zone Multi-Server | Deliberate (same DC or region) | 1 | All roles | Enterprise: Single region |
| RA4: Multi-Zone Multi-Server | Deliberate (same DC or region) | 1 per region | All roles + zone isolation | Enterprise: Global multi-region |
The transitions between stages are additive rather than replacement. Moving from RA2 to RA3 means separating the database onto a dedicated server and adding a second Web App node behind a load balancer. Moving from RA3 to RA4 means defining additional zones with region-specific infrastructure while keeping the Web App role and database anchored at the central site.
Architecture selection is driven by session concurrency, fault tolerance, and geographic distribution requirements. The choice of hypervisor or cloud provider does not determine which reference architecture to select.
Proceed to the following sections that build on these foundations.