Platform
Remote Desktop
Your machine already runs in a browser tab — which means its screen is already one link away from anyone you want looking at it. brintOS Remote Desktop shares a live machine's display with other people in real time: they open the link, see your framebuffer in their own tab, and — if you let them — type and click as if they were sitting at it. No client to install, no plugin, no meeting software.
Sharing a screen the way you share a repo
Every running machine has a Share button. Click it and you get a session link; anyone who opens that link sees the machine's display — console, framebuffer, or full desktop — streaming live in their own browser. It is the machine's real screen, not a screenshot loop or a re-rendered approximation: the same virtio-gpu framebuffer your tab renders is what theirs renders.
Access follows the same model as everything else on brintOS. A link can be scoped to specific users, to your organization, or opened to anyone who has it; viewers of a restricted session sign in first, and the session list shows you exactly who is connected at any moment. Revoke the link and every viewer drops instantly.
View-only by default, hands-on by grant
- Viewers watch. By default a shared session is view-only: guests see the screen and your cursor, and nothing they do reaches the machine.
- Input is granted per person, live. When someone needs the keyboard, you hand it over from the session panel — one click grants that viewer input, one click takes it back. Their keystrokes and pointer events feed into the machine's input devices exactly as yours do, so from Linux's point of view there is still just one seat.
- Everyone sees the same thing. There is no "presenter view" desync — every participant is looking at the same framebuffer, frame for frame, with each participant's cursor visible and labeled so "click the icon next to my cursor" actually works.
What people use it for
- Technical support. "It doesn't work" becomes "show me." A user shares their machine, the support engineer watches the failure happen, takes input, fixes it, and hands the keyboard back — without shipping a screen-recording, scheduling a call, or installing remote-control software on anyone's laptop. Because the machine itself is shareable, support can also fork a snapshot and reproduce the problem offline.
- Collaboration. Pair programming with a real second seat: your partner watches you work, takes the keyboard for their half, and the machine never leaves your control. For code review, walking someone through a live system beats reading a diff of it.
- Education. An instructor shares one machine to a room — or a hundred students each share theirs back. Lab TAs hop between student sessions from a list, watch where someone is stuck, and take input to demonstrate. Since machines are snapshots, the instructor's exact demo environment is also one Launch click away for every student afterwards.
- Demos and walkthroughs. Send a prospect a link and drive a live product demo in their browser — or grant them input and let them drive, on your machine, with nothing to set up on their side and nothing left behind on yours.
How it works
The host tab is the source of truth: HardwareJS already owns the machine's virtio-gpu framebuffer and input queues, so sharing is a matter of fanning the display out and feeding granted input back in.
- Video rides WebRTC. The host tab encodes the framebuffer as a hardware video stream and each viewer receives it over a peer connection — the same path used by video calls, tuned for screen content (text stays crisp, motion stays smooth). Small sessions connect browser-to-browser; larger audiences fan out through brintOS relays so the host's uplink carries one stream, not fifty.
- Input rides the data channel. A granted viewer's key and pointer events travel back on the session's data channel and are injected into the machine's virtio-input devices, tagged per participant. Latency is a round trip, not a video pipeline — typing feels local.
- Everything is encrypted end-to-end between participants' browsers. Relayed sessions forward ciphertext; brintOS cannot watch your screen, and nothing about a session is recorded unless the host explicitly turns recording on.
The machine stays yours
Screen sharing never changes who owns the seat. Viewers hold no credential to the machine — when the session ends, they have nothing: no account on the box, no lingering agent, no access token to expire. If you want a collaborator to have the machine itself, that's what sharing the machine is for; Remote Desktop is for sharing the moment.
Included where you'd expect
View-only sharing with one guest is free on every plan — enough for "look at this real quick." Multi-viewer sessions, input granting, org-scoped links, and session recording come with Team; Enterprise adds relay pinning to your own infrastructure so session traffic never crosses ours, alongside the same VPC story as the NIC and org VPN.