(RA1) Single Server Architecture Explained
The Single Server architecture, designated RA1, is often described as the simplest way to deploy Kasm Workspaces. That description is accurate from an operational perspective. It is misleading from an architectural perspective.
RA1 is not a reduced version of the platform, it is a collapsed version of the platform. Every logical role that exists in the most sophisticated multi-region Kasm deployment also exists in RA1. The Web App, the Database, the Agent, the Connection Proxy, and the session delivery infrastructure are all present. What is absent in RA1 is the separation between those roles.
Understanding RA1 is therefore less about understanding the diagram, which shows a single server, and more about understanding what disappears when all roles are collapsed onto one machine and what the consequences of that collapse are.
Reference Architecture 1
The Primary Load Balancer
Each Kasm Web App role includes an NGINX container kasm_proxy that serves as a required front-end to internal services. While this component is integral to system operation, organizations may enhance their security posture by either hardening this configuration or deploying Kasm Workspaces behind an enterprise-grade reverse proxy or load balancer.
Enterprise security solutions can provide advanced protections such as Web Application Firewall (WAF) capabilities, DDoS mitigation, and Zero Trust access controls. Additionally, SSL/TLS offloading can centralize traffic management and reduce processing overhead on backend Kasm services, improving both performance and resource efficiency.
All user interactions, authentication, session initiation, and workspace streaming enter the environment through a single public endpoint, the Primary Load Balancer. This abstraction presents the deployment as a unified service, regardless of the underlying architecture.
For production deployments, a network load balancer is the recommended approach.
The Defining Characteristic: Role Collapse
In more advanced Kasm architectures, responsibilities are distributed to separate infrastructure tiers. In RA1, all roles run on the same host, share the same compute resources, and are exposed through the same network identity. This creates a system with:
- No internal network topology between roles
- No trust boundaries between roles
- No independent scaling of any role
The architecture still behaves like Kasm. Sessions are authenticated, workspaces are provisioned, containers are launched, and sessions are streamed. The absence of role separation means that none of the structural protections that larger architectures provide are present. A resource spike in the Agent tier, where workspace containers consume CPU and memory, directly affects the Web App tier on the same host. A database failure is simultaneously a control plane failure, a session provisioning failure, and a state persistence failure, because all three functions share the same machine.
The Illusion of Simplicity
RA1 feels simple because there is one hostname, one server, and one deployment unit. Internally, the system is performing:
- API orchestration
- Session scheduling
- Container execution
- Protocol translation
- State persistence
These functions are not simplified in RA1. They are co-located.
RA1 reduces deployment complexity, not architectural complexity.
This distinction matters because it shapes how RA1 should be evaluated. An Enterprise Architect who concludes that Kasm is architecturally simple because RA1 appears simple has misinterpreted what they are looking at. RA1 is the architecture that results when all boundaries are deliberately removed. Its simplicity is a consequence of collapsed boundaries, not of an inherently simple system.
Two Session Types, One Control Plane
RA1 supports two fundamentally different session types that share a control plane but diverge after session creation.
Containerized workspaces are launched on external Docker Agents and delivered as ephemeral containers. These sessions benefit directly from the distributed execution model: capacity for containerized workspaces scales with the number of Agent nodes registered to the control plane.
Remote system access sessions connect to existing Windows, Linux, and macOS systems via RDP, VNC, or SSH. These sessions are mediated through the Connection Proxy on the control plane server, which translates legacy protocols into browser-native streams. The execution target is an existing system, not a container provisioned by Kasm.
Both session types share the same authentication flow and the same control plane. The difference lies in where execution occurs and what infrastructure hosts it.
The Control Plane and Execution Plane Share a Boundary
In distributed architectures, the control plane makes decisions and the execution plane carries them out. Separating them allows each to scale, fail, and be maintained independently.
In RA1, the Web App role decides where to run a session, and the Agent role executes that session, but both exist on the same machine. There is no network boundary between decision-making and execution. There is no resource isolation between orchestration and workload. The system loses its ability to separate the responsibility for decisions from the capacity to execute them.
This becomes visible under load. As user concurrency increases, workspace containers compete for the same CPU and memory that the Web App API and the database require to function. In a distributed architecture, Agent load is isolated from control plane load. In RA1, they are the same load on the same hardware.
The Database: State Without Isolation
Even in RA1, the database remains the single source of truth for user sessions, configuration, and authentication state. Its role is not simplified in any architectural sense. It stores exactly the same data it would store in an RA3 or RA4 deployment.
What changes in RA1 is that the database shares its compute, memory, and failure domain with every other role on the system. In larger architectures, the database occupies a dedicated, isolated segment. In RA1, the most critical component in the system has no isolation from any other component. This is the most significant architectural property of RA1 from a resilience perspective.
In RA1, any failure is a total failure. A hardware failure, a kernel panic, an out-of-memory condition, or a network disruption affects every role simultaneously.
DNS and Identity: A Single Point of Truth
RA1 typically uses a single public hostname, for example kasm.example.com. This hostname represents the Web App, the Proxy, and the session endpoint simultaneously. Because everything is on one server:
- Browser origin rules are trivially satisfied
- TLS configuration requires only a single certificate for a single hostname
- No cross-domain considerations exist
This simplicity makes RA1 the clearest environment in which to observe how Kasm behaves when identity, transport, and execution share a single domain. The DNS and TLS requirements that become more complex in distributed architectures are visible here in their simplest possible form. Even at this scale, TLS must match the configured hostname, WebSocket origin must match, and the Proxy Hostname must resolve identically. These requirements do not relax in RA1: they are simply easier to satisfy because everything resolves to one address.
What RA1 Reveals About Kasm's Design Philosophy
Despite its limitations as a production architecture, RA1 reveals the core design philosophy of the platform clearly:
The system is inherently multi-role. Even when collapsed onto a single host, distinct responsibilities exist and are executed by distinct services. The architecture does not disappear in RA1: the boundaries between roles are simply not enforced by physical or network separation.
The browser is the universal client. All access is mediated through web-native protocols regardless of the complexity of the underlying execution environment. RA1 makes this particularly clear because there is no complex proxy topology to obscure the basic relationship between browser and platform.
Sessions are ephemeral workloads. Workspaces are created and destroyed on demand in RA1 exactly as they are in RA4. The ephemerality of sessions is not a feature of large-scale deployments: it is a property of how the platform works at every scale.
The control plane governs everything. All decisions about authentication, session placement, and policy evaluation originate from the Web App role, even when that role is co-located with everything else.
RA1 in the Deployment Progression
RA1 occupies a specific and intentional position in the deployment progression. It is the starting point, the baseline for understanding, and the architecture that exposes what must change to achieve resilience.
| What RA1 Lacks | What It Teaches |
|---|---|
| Isolation between roles | Why role separation is the foundation of all resilience improvements |
| Independent scaling of any tier | Why statelessness of the Web App role is architecturally significant |
| Database resilience | Why the database is the single most critical HA investment |
| Any partial failure mode | Why the difference between control plane and session plane failures matters |
RA1 is not an endpoint, it is a point of departure. It demonstrates a complete Kasm system in its most compressed form: control plane, execution plane, transport, and state all co-located, sharing a single identity, a single failure domain, and a single boundary.
From an enterprise perspective, the key realization is this: RA1 is designed for understanding, not resilience. Because once you understand what RA1 lacks, you understand exactly why the rest of the architecture exists.
This article is part of the Kasm Workspaces Reference Architecture Explanation Series.