(RA2) Single Server Control Plane with External Docker Agents Architecture Explained
The RA2 architecture is frequently described as RA1 with more servers. That description is accurate about the hardware involved. It is misleading about what changes architecturally.
RA2 is the first meaningful separation of responsibility in Kasm Workspaces. It introduces the most fundamental structural distinction the platform makes: the separation between decision-making and execution. In RA1, the same machine both decides where a session runs and runs it. In RA2, the control plane still decides, but the execution happens elsewhere.
This is not a configuration change. It is the beginning of a distributed system.
Reference Architecture 2
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.
From Consolidated to Distributed
In RA1, everything happens in one place. In RA2, one change fundamentally alters the system's character: the Agent function moves to external nodes.
The control plane remains centralized. The single Kasm server in RA2 still contains the Web App, the Database, and the Connection Proxy. It is still the authoritative core of the system, handling authentication, policy evaluation, session scheduling, and state persistence. From the browser's perspective, the entire platform still appears as a single endpoint with a single identity.
But the execution plane has become distributed. External Docker Agents run on separate infrastructure, host containerized workspace sessions, and provide scalable compute capacity no longer constrained by the resources available on the control plane server.
| Role | RA1 Location | RA2 Location |
|---|---|---|
| Web App | Single server | Single server (unchanged) |
| Database | Single server | Single server (unchanged) |
| Connection Proxy | Single server | Single server (unchanged) |
| Docker Agent | Single server | External Docker Agent nodes |
The architectural consequence of this separation is that workloads no longer run where decisions are made. The system has acquired the most basic property of a distributed architecture: different functions occurring on different machines, coordinated through a defined interface.
Three Traffic Flows Define the Architecture
Reading RA2 correctly requires understanding it as a system of flows rather than a collection of components.
The control plane flow handles authentication and orchestration. This flow runs between the user's browser and the single Kasm control plane server. The user authenticates, requests a workspace, and receives session connection details. This flow is entirely contained within the control plane server.
The execution flow handles workload instantiation. When the control plane selects an external Agent for a session, it instructs that Agent to provision a container. This flow runs between the control plane server and the external Agent nodes over internal network paths.
The session plane flow handles workspace streaming. Once a container is running on an external Agent, the user's browser connects to it through the Connection Proxy on the control plane server. This flow runs from the user's browser, through the control plane server's proxy, to the external Agent hosting the container.
Understanding RA2 is understanding how these three flows diverge after session creation.
Two Session Types, One Control Plane
RA2 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.
Asymmetrical Failure Behavior
RA2 introduces something RA1 cannot provide: asymmetrical failure behavior.
When an Agent node fails in RA2, only the sessions running on that specific Agent are interrupted. Users on other healthy Agents continue working unaffected. New sessions are scheduled to remaining healthy Agents automatically.
When the control plane server fails, no new sessions can be created, authentication fails for new connections, and the entire management interface becomes unavailable. Existing sessions already streaming between a browser and an Agent may continue briefly, because the session plane is database-independent mid-stream, but they cannot be re-authenticated and will eventually terminate.
RA2 is partially resilient, not highly available. Organizations that require control plane fault tolerance need RA3 or higher. RA2 is appropriate for capacity expansion beyond a single server and for environments where control plane downtime during maintenance windows is acceptable. It should not be treated as a production-grade HA architecture.
What RA2 Reveals About Kasm's Design Philosophy
RA2 exposes several core principles of the Kasm design that RA1 cannot demonstrate, because RA1 collapses everything into one place.
Centralized control with distributed execution is not just a scaling pattern. It is the foundational structure of the platform. The control plane governs everything: it authenticates, authorizes, schedules, and records. The execution plane does exactly what it is told and nothing more.
Zero trust mediation is architecturally enforced, not configured. Users cannot connect directly to workloads because the architecture does not provide a path for them to do so. The Connection Proxy is the only path, and it validates every connection against the control plane.
Sessions are disposable and location-independent. When a container runs on an external Agent in a different part of the data center, the user's experience is identical. The location of execution is an infrastructure detail that the architecture deliberately abstracts away.
RA2 in the Architectural Progression
RA2 demonstrates that the execution plane can be distributed without any fundamental change to the control plane. It also reveals what remains unresolved: control plane redundancy, database resilience, and proxy distribution.
For an Enterprise Architect, the key realization RA2 offers is this: RA2 is where infrastructure stops being a collection of servers and starts becoming a coordinated system of roles. Once that shift happens, the question that follows naturally is: if the execution plane can be distributed, why not the control plane as well?
This article is part of the Kasm Workspaces Reference Architecture Explanation Series.