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.

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.

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.