How the desktop stream connects, direct or through a relay, what it needs from your network, and what to do when it is slow or doesn't connect.
How the stream travels
Signing in, the link and the setup of the stream go through kiste.run over HTTPS. The video and audio themselves travel as an encrypted WebRTC stream (DTLS-SRTP) over UDP: directly between your browser and the computer that runs the Kiste when possible, or through a relay operated by Cloudflare when a direct path isn't available. The overlay's details show which path is in use.
A direct path has the lowest latency. A relayed path adds a few tens of milliseconds and is otherwise the same. The picture's quality and frame rate adapt continuously to what the connection carries, and the stream recovers from lost packets on its own.
What your network needs
- HTTPS to
kiste.runanddesktop.kiste.run. - Outgoing UDP. Most home, office and mobile networks allow it.
Networks that block all UDP, and some VPNs, can prevent the stream from starting (D03). Try another network or turn the VPN off for a moment to see whether that is the cause. Terminal access with SSH needs only HTTPS and works on such networks.
When it feels slow
- Look at the overlay's details: a high round-trip time (RTT) or a low frame rate points at the network.
- A smaller window or a smaller UI size sends fewer pixels.
- Wi-Fi far from the router, or a busy link, costs most; a cable or a 5 GHz network helps.
- An app in the Kiste that keeps its CPU busy slows its desktop too:
kiste status NAME --usageshows it.
When it drops
If the stream ends at the same moment as other connections from your computer (an SSH session, a video call), the cause is usually your computer's network, not the Kiste. The viewer reconnects by itself when the network is back.
If the stream doesn't come back, press Reconnect in the overlay. If the video stream can't start at all, the recovery console shows the screen another way.