How CTRL is built.

The problem

Reach any of your devices from any other, over the internet, without handing your screen to a middleman. That rules out streaming everything through a server, so CTRL connects the two devices directly and uses its servers only to introduce them.

The connection

Devices connect with WebRTC: the picture, sound, mouse, keyboard, clipboard and files travel in one encrypted peer-to-peer link (DTLS-SRTP). When a network blocks a direct path, traffic goes through a relay that only sees encrypted data. The viewer adapts quality to the link, moves to a new network when yours changes, and refreshes relay credentials during long sessions.

The introduction

A Supabase backend holds accounts, paired devices and a history of who connected to what. Every table is guarded by row-level security so an account only ever sees its own devices. Session requests and signalling travel on private realtime channels that the database itself authorises, so a device cannot forge a request. Pairing a device means approving a short code from a device you already trust.

Safety by design

• Nothing from a session is recorded or stored by CTRL.
• The controlled device can approve each session, pause it, end it, or hit a panic shortcut.
• Held keys and mouse buttons are released automatically if the controller goes quiet.
• Sensitive actions (like waking a PC) are checked on the server against the device’s own reported details, never against what the caller sends.

One codebase, three apps

A shared TypeScript package holds the protocol, the connection logic, input mapping and touch gestures. The web app (React) is also the Windows app’s interface inside Electron; Android uses Expo with a small Kotlin module for the foreground service and accessibility input. Message formats are defined once as schemas and checked on both ends, so older apps keep working when new features appear.

Read more

The security overview and privacy page say what is kept and what never is. The changelog lists what changed and when.