Architecture

ZynoRMM has three main components: the agent, the bridge, and the technician client. This page explains how they fit together and how data flows between them.

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 itself collecting non-sensitive monitoring data (system info, hardware inventory, installed software).

Bridge

The bridge is the central relay service. It maintains WebSocket connections to all agents on one side and all technician clients on the other. Its job is to route requests from technicians to the correct agent and relay responses back.

Critically, 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 for sensitive operations, the payload contents are encrypted end-to-end between the technician and the agent — the bridge sees only ciphertext.

The bridge does independently collect non-sensitive monitoring data from connected agents — system information, hardware inventory, and installed software — so that the management UI can display endpoint status without requiring a technician to initiate each query. This data is limited to read-only telemetry that carries no sensitive side effects. See Operation Security for the full classification.

Technician Client

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

• Authenticating the technician via hardware-backed WebAuthn (passkeys, security keys, or platform biometrics)
• Cryptographic signing of 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, encryption — happen client-side in the browser. Private keys never leave the technician's device.

Data Flow

Command Operations

For standard operations like fetching system info, running a command, or listing files:

1. The technician's browser signs the request with their 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.

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 (SDP offers/answers, ICE candidates) through the bridge — but the signaling itself 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 using native platform APIs (ScreenCaptureKit on macOS, DXGI Desktop Duplication on Windows) and encodes it as H.264 using hardware acceleration (VideoToolbox on macOS, Media Foundation on Windows)
5. Video frames are streamed over an unreliable WebRTC data channel for low latency
6. Keyboard and mouse input flows back over a reliable WebRTC data channel
7. All WebRTC traffic is encrypted via DTLS — the bridge has no access to the video stream or input events

If a direct peer-to-peer connection isn't possible (e.g., due to NAT), traffic can be relayed through a TURN server, but it remains encrypted end-to-end.

File Transfer

File transfers also use WebRTC data channels, following a similar pattern to screen sharing — encrypted end-to-end, direct between the technician's browser and the agent.

Terminal Sessions

Terminal sessions run over a real PTY on the endpoint, with input/output streamed in real-time through WebRTC data channels.

Platform Support

Capability	macOS	Windows	Linux
Screen sharing & remote control	Yes	Yes	--
Terminal sessions	Yes	Yes	Yes
Command execution	Yes	Yes	Yes
File management & transfer	Yes	Yes	Yes
System info & 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	Encrypted file (TPM planned)	Encrypted file

Monitoring & Management

The bridge continuously tracks the state of every connected agent:

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

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

Organizations

Endpoints can be grouped into organizations for multi-tenant MSP workflows — each of your clients' devices organized under their own group, with technician access scoped accordingly.