Should you build your own TeamViewer?
Remote desktop control and remote support sessions across machines and platforms.
If you only need to reach your own machines, most of TeamViewer's value is reproducible: screen capture, a WebRTC pipe, and synthetic mouse and keyboard events are all solved problems with libraries. An agent can wire that into a working host agent plus browser viewer in a weekend, and on your own LAN it will feel fine. What breaks is everything outside your control: connecting through hostile double NAT without your own TURN server, waking a sleeping box, keeping latency sane over mobile networks, and surviving OS permission prompts on macOS after every update. It also stops being a support tool, because the whole point of TeamViewer for helping your parents is that they can install one thing and read you a nine digit number. Build it for your own boxes, keep paying if you support other people's.
ENOriginal research content in English. Original prompt preserved in English.
Build a self-hosted personal remote desktop system: a host agent I run on machines I own, and a browser viewer I open to control them.
Stack, no substitutions:
- Node 20 + TypeScript for both host agent and signaling server.
- WebRTC via the werift library on the host side, plain browser WebRTC on the viewer side.
- ffmpeg (spawned as a child process) for screen capture and H.264 encoding.
- @nut-tree-fork/nut-js for mouse and keyboard injection on the host.
- Signaling over WebSocket (ws), single small server, no framework.
- Viewer is one static HTML file with vanilla JS and a canvas/video element. No React, no build step for the viewer.
Structure:
- /signal: WebSocket signaling server. Hosts register with an ID and a shared secret from .env. Viewers authenticate with the same secret, then get relayed SDP and ICE.
- /host: the agent. Captures the primary display with ffmpeg (avfoundation on macOS, gdigrab on Windows, x11grab on Linux), pipes encoded video into a WebRTC track, opens a data channel, and applies incoming input events with nut-js.
- /viewer: static page. Shows available hosts, connects, renders the video track, captures mouse move/down/up/wheel and keydown/keyup, normalizes coordinates to the remote resolution, sends them over the data channel.
Rules:
- All config in .env: SIGNAL_URL, SHARED_SECRET, HOST_ID, TURN_URL, TURN_USER, TURN_PASS. Ship .env.example. Never hardcode secrets.
- No accounts, no database, no telemetry, no cloud services beyond the signaling server and TURN that I run.
- Target 1080p at 25fps with a tunable bitrate and a keyframe interval short enough to recover fast. Prefer latency over quality.
- Data channel messages are small JSON objects, unordered, unreliable for mouse moves and ordered/reliable for clicks and keys.
- Include a --view-only flag on the host that ignores all input events.
- Log connection state transitions clearly so I can tell whether ICE failed or the encoder died.
Explicitly out of scope: file transfer, clipboard sync, multi-monitor selection, mobile clients, unattended wake, NAT traversal magic beyond standard STUN/TURN.
Deliverables: working code, one README with exact setup commands per OS, the macOS Screen Recording and Accessibility permissions steps, and a coturn config snippet I can drop on a VPS.The prompt opens pre-filled in your agent. Review it before running. · this prompt is generated from the build plan · improve it via PR
What would building your own look like?
A host agent on each of your machines streams its screen over WebRTC to a password-protected browser viewer that injects your mouse and keyboard events back.
What you will need
- Node 20 on every machine you want to control
- ffmpeg installed on each host
- A cheap always-on VPS for signaling and a coturn TURN server
- Screen Recording and Accessibility permissions on macOS, or an X11/Wayland session that allows input injection on Linux
- A domain with TLS, because getUserMedia and secure contexts will fight you otherwise
Because remote access is only worth anything when it connects on the first try from a network you have never seen, to a machine you cannot physically touch, running an OS version you did not choose. TeamViewer sells that reliability plus the legal cover to use it at work. Personal self-hosted remote desktop is genuinely pleasant right up until you are in an airport and your TURN server is the thing that died.
xConnections that just work through carrier grade NAT, corporate firewalls, and proxies without you operating relay infrastructure
xNative clients for Windows, macOS, Linux, iOS, and Android, plus mobile device support
xThe support workflow: a one-click download and a session code a non-technical person can read to you over the phone
xUnattended access extras: wake on LAN, reboot and reconnect, multi-monitor switching, file transfer, session recording, printing
xCommercial licensing, audit logs, and the corporate compliance story that makes IT allow it at all
Nothing worth pointing at. That’s why the prompt exists.
How much does TeamViewer cost?
- Monthly billing
- $24.90/mo$24.90/mo · per person
- Per year
- $299/yr$299/yr
- On a Brazilian card, with 3.5% IOF
- R$130/moR$1,561/yr
Saved to My list. You will see a notice on this site when the price changes.
You complete the purchase on TeamViewer’s site. Vibe Radar does not handle payments.
Is it cheaper to build or buy TeamViewer?
Adjust the numbers: hours to build, your hourly rate, running costs and the subscription price.
Over 24 months, subscribing is cheaper.
Starting hours estimated from the analysis (a weekend). Does not price what you give up (support, integrations, security).
Can I rebuild TeamViewer?
Kinda. The core of TeamViewer is buildable in a weekend with the prompt on this page, but there are real gaps: Connections that just work through carrier grade NAT, corporate firewalls, and proxies without you operating relay infrastructure, Native clients for Windows, macOS, Linux, iOS, and Android, plus mobile device support. Read the honest list above before committing.
How much does TeamViewer cost?
TeamViewer costs about $24.90/mo (TeamViewer Remote Access, checked 08/18/2026), which is $299 per year.
What do I lose by replacing TeamViewer?
Honestly: Connections that just work through carrier grade NAT, corporate firewalls, and proxies without you operating relay infrastructure; Native clients for Windows, macOS, Linux, iOS, and Android, plus mobile device support; The support workflow: a one-click download and a session code a non-technical person can read to you over the phone; Unattended access extras: wake on LAN, reboot and reconnect, multi-monitor switching, file transfer, session recording, printing; Commercial licensing, audit logs, and the corporate compliance story that makes IT allow it at all. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to TeamViewer?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.