Self-hosted remote desktop: a build guide
Securely controlling a PC on another network takes more than screen streaming. You also need a server where the two PCs find each other and negotiate a path, technology that traverses firewalls and NAT, and encryption that protects screen, input, and files. This guide breaks a self-hosted remote desktop into the three building blocks it needs — connect (NAT traversal), session (screen and input), and server (coordinator, relay, gateway) — then shows how to start with a finished app or build your own with the SDKs.
Why self-host a remote desktop
Teams reach for a self-built remote desktop for roughly three reasons. First, data sovereignty — screen, input, and files must never leave servers the organization itself runs. Second, closed / internal networks — you need to reach a PC on another network even where internet access is controlled. Third, cost and vendor lock-in — teams monitoring many PCs around the clock often want to fix costs with a self-run server instead of a per-user or per-session cloud SaaS bill. Self-hosting puts control over all three squarely in the organization's hands.
Three building blocks — connect, session, server
Break a remote desktop into parts and you get the three below. Finished NetServ apps like Classic and WebRTC run on exactly this stack.
🔌 Connect
The layer where two PCs on different networks find a path to talk directly — direct P2P via NAT hole-punching where it works, automatic relay fallback where it doesn't.
🗂️ Session
Screen capture, encoding and transport, keyboard/mouse input injection, and clipboard/file transfer.
🧩 Server
A coordinator that brokers discovery, a relay that forwards traffic when a direct link isn't possible, and a WSS gateway that keeps browsers connected too.
NetServ ships each layer as an SDK — ConnectKit (connect), SessionKit (session), and ServerKit (server) — that you can assemble into your own product.
Start with a finished app — Classic and WebRTC
You don't have to assemble the SDKs to get started today. Classic is an installable desktop app for both ends, tuned for always-on monitoring (MultiView) on closed / internal networks, and recent versions also ship an install-free browser web viewer. WebRTC lets the viewer side connect from a browser with no install and is strong on accounts, roles, and permissions managed per organization. Both encrypt screen, input, and files end-to-end, and both let you self-host the connection servers so data never leaves your org.
| Aspect | Classic | WebRTC | Build with the SDKs |
|---|---|---|---|
| Install | Installable app on both ends | Host installs; viewer uses a browser | SDK embedded in your app |
| Best fit | Always-on monitoring on closed networks | Easy external access · helpdesk | Your own product / brand |
| Encryption | End-to-end (J-PAKE) | End-to-end (DTLS-SRTP) | ConnectKit end-to-end |
| Server | Self-host option (introducer · gateway · relay) | Self-host gateway option | Self-hosted ServerKit |
| Price | Free now | Free now | ConnectKit free + paid SDK Pro / ServerKit tiers |
Connecting on any network
Linking two PCs behind firewalls and NAT — at home, in an office, on a closed network — is the hardest part of a self-hosted remote desktop. Where hole-punching works, the two ends connect directly (P2P); where it's blocked, they fall back automatically to a relay; and in restrictive environments like a browser, a WSS (443) gateway keeps the connection working. The session key is created only on the two ends, so no server in the middle can see screen or input.
Security and audit
Self-hosting doesn't mean designing security from scratch. End-to-end encryption applies the same way regardless of who runs the server; add session recording with an integrity hash and a central console's role management (RBAC) and access policy, and you have a system you can audit for who did what and when. For regulated or high-security organizations, that audit trail also needs to stay inside their own infrastructure — which is often why self-hosting the server becomes a requirement, not a preference.
Building it yourself with the SDKs
To embed remote control in your own product or brand, combine the three SDKs: connection via ConnectKit (free forever), screen and input via SessionKit (Standard is free; advanced features like hardware H.264 need a Premium license), and the broker server via ServerKit (self-hosted, free up to 5 peers, then paid tiers by peer scale). See exact pricing per configuration on the Pricing page.
Frequently asked questions
Does self-hosting a remote desktop really keep data from leaving?
Run the connection servers (coordinator, relay, gateway) yourself and screen, input, and files never leave that
server boundary. That said, sessions are end-to-end encrypted regardless — even without self-hosting, the
server can't see session content. Self-hosting is specifically about keeping the server infrastructure itself
inside your organization's boundary.
Should I try Classic or WebRTC first?
For always-on monitoring of many PCs on a closed / internal network, try Classic first; for easy access from
outside or when you need accounts and role management, try WebRTC first. Both are free right now and run on the
same connectivity infrastructure.
What components do I need to build my own with the SDKs?
Combine ConnectKit (free) for the connection, SessionKit (Standard free, advanced features Premium) for screen,
input, clipboard, and files, and ServerKit (self-hosted, free up to 5 peers) as the broker server that lets the
two devices find each other.
Can I self-host completely for free?
ConnectKit is free forever and ServerKit is free up to 5 peers. Classic and WebRTC themselves are also free
right now. Beyond that scale, or once you need SessionKit Premium features (like hardware H.264), paid licenses
apply by developer seat or peer scale.