ZynoRMM Architecture

This technical reference explains how ZynoRMM components communicate. For technician workflows, see ZynoRMM.

ZynoRMM has three main components: the agent, the bridge, and the technician client.

Components

Agent

The agent is a lightweight, native application written in Rust that runs on each managed endpoint. It supports macOS, Windows, and Linux and runs as a system service for persistent, unattended operation (launchd, Windows Service, or systemd).

On startup, the agent establishes a persistent WebSocket connection to the bridge. All communication is binary protobuf — compact and efficient, even on constrained networks. The connection includes automatic reconnection with jittered delays and application-level keepalive pings to detect dead connections quickly.

The agent never opens inbound ports. It responds to requests relayed through the bridge — either from technicians performing operations or from the bridge collecting non-sensitive monitoring data, such as system information, hardware inventory, and installed software.

Bridge

The bridge is the central relay service. It maintains WebSocket connections to agents and technician clients, routes requests to the correct agent, and relays responses back.

The bridge is a relay, not an authority. It forwards signed requests but cannot forge them. It can see that an operation is happening and what type it is, but sensitive-operation payloads are encrypted end-to-end between the technician and agent, so the bridge sees ciphertext.

The bridge independently collects non-sensitive monitoring data from connected agents so the management UI can display endpoint status without a technician initiating each query. This data is limited to read-only telemetry that carries no sensitive side effects. See What Requires Authorization for the full classification.

Technician client

The technician client is a browser-based SDK that runs in the technician's browser. It handles:

• Authenticating the technician with hardware-backed WebAuthn, such as passkeys, security keys, or platform biometrics
• Cryptographically signing every sensitive operation
• End-to-end encryption of payloads
• WebRTC peer connections for screen sharing, file transfer, and terminal sessions

All cryptographic operations — key generation, signing, and encryption — happen client-side in the browser. Private keys never leave the technician's device.

Data flow

Sensitive technician operations

For a sensitive technician operation, such as running a command, listing a directory, reading or writing a file, or controlling a service:

1. The technician's browser signs the request with its session key and encrypts the payload.
2. The signed request is sent to the bridge over WebSocket.
3. The bridge wraps it in an audited envelope and relays it to the target agent.
4. The agent verifies the full signature chain and all security checks before executing.
5. The agent encrypts the response and sends it back through the bridge.
6. The technician's browser decrypts the response.

The bridge never sees the plaintext of encrypted request or response payloads.

Bridge-initiated monitoring

The bridge can collect a deliberately limited set of non-sensitive telemetry and discovery data without a technician signature: system information and utilization, hardware and installed-program inventory, service and display lists, network diagnostic observations, and disk device or mount paths reported as inventory. The bridge can read that telemetry so it can present endpoint status in the management UI.

Arbitrary browsed paths, directory contents, and per-entry file metadata are not bridge-readable telemetry. File browsing is available only after a signed and encrypted file-transfer session is established.

Screen sharing

Screen sharing uses WebRTC for direct peer-to-peer video and input streaming:

1. The technician requests a screen session through the bridge.
2. The agent and technician exchange WebRTC signaling, including SDP offers, answers, and ICE candidates, through the bridge. The signaling is encrypted end-to-end via ECDH, so the bridge cannot see the connection details.
3. A direct WebRTC peer connection is established between the agent and the technician's browser.
4. The agent captures the screen with native platform APIs — ScreenCaptureKit on macOS and DXGI Desktop Duplication on Windows.
5. Frames are encoded one of two ways, chosen at runtime in the default mode: as Zstd-compressed delta patches covering only the screen tiles that changed, or as hardware-accelerated H.264 once the screen is full-motion. H.264 is also the fallback when the viewer cannot decode delta or when delta recovery falls behind.
6. Video frames stream over unreliable WebRTC data channels for low latency.
7. Keyboard and mouse input flow back over a reliable WebRTC data channel.
8. All WebRTC traffic is encrypted with DTLS, so the bridge has no access to the video stream or input events.

If a direct peer-to-peer connection is not possible, such as because of NAT, traffic can be relayed through a TURN server while remaining encrypted end-to-end.

File transfer

File transfers use WebRTC data channels, encrypted end-to-end and direct between the technician and agent.

Terminal sessions

Terminal sessions run over a real PTY on the endpoint, with input and output streamed in real time through WebRTC data channels. The bridge routes the signaling needed to establish the connection, but terminal I/O flows directly between the technician and agent.

Agent platform support

Capability	macOS	Windows	Linux
Screen sharing and remote control	Yes	Yes	—
Terminal sessions	Yes	Yes	Yes
Command execution	Yes	Yes	Yes
File management and transfer	Yes	Yes	Yes
System information and inventory	Yes	Yes	Yes
System services	Yes	Yes	Yes
Network tools	Yes	Yes	Yes
Network tunnels	Yes	Yes	Yes
Service mode	launchd	Windows Service	systemd
Agent identity storage	Keychain, Secure Enclave where available	Protected local storage, TPM-backed where available	Encrypted file

Monitoring and management

The bridge continuously tracks every connected agent's state:

• Connection status — real-time online/offline state with connection history
• System information — hostname, OS, domain status, and logged-in users, refreshed on connection and periodically
• Hardware inventory — component-level tracking with change detection for components added, removed, or changed over time
• Installed software — program inventory with version tracking and change history
• User sessions — login and logout events tracked historically

Changes are published as real-time events through Server-Sent Events (SSE), so the management UI updates when an agent connects, a user logs in, or hardware changes.

Organizations

Endpoints can be grouped into organizations for multi-tenant MSP workflows. Each client's devices are organized together, with technician access scoped accordingly.

Related

• ZynoRMM
• Remote Support Sessions
• Network Discovery
• ZynoRMM Security Model