Remote desktop for a headless Linux server

The install script registers the user service automatically; the two systemctl lines are spelled out so you know what's getting enabled.

Why this is its own page (not just “Linux”)

The headless case has different ergonomics. There's no system browser to open, no portal dialog to click through, no display attached. You're SSH'd in. Most remote desktop tools assume someone is sitting in front of the machine the first time it boots. Scry has a dedicated device-code path for the headless case — one short command, paste a code into a browser somewhere else, done.

The headless install path, end-to-end

1. 1. SSH into the server

   From any machine. The server can be behind a NAT, in a homelab, or in a cloud VM. The Scry install does not require root.

2. 2. Run the install one-liner

   curl -fsSL https://bravely.dev/scry/install.sh | bash — detects your distro (Ubuntu/Debian, Fedora/RHEL, Arch), installs ffmpeg + xdotool + the .NET 8 runtime if missing, drops the systemd user unit, and prints the next step.

3. 3. Pair with a device code

   scry login. The CLI prints a short URL and a 6-character code. Open the URL on a phone, laptop, anywhere with a browser, sign in to your Bravely account, paste the code. The Linux host saves a refresh token and never asks again.

4. 4. Enable the systemd user service

   systemctl --user enable --now scry-linux-host. To survive logout, loginctl enable-linger $USER. The host is now reachable from your Scry account on Mac, Windows, or the browser viewer.

5. 5. Connect

   From any other Scry client, pick the server out of your devices list. WebRTC negotiates a peer connection (or relays if your network needs it), the X11 session streams, your input gets injected. No port forwarding ever happened on your router.

What the systemd user service buys you

• Survives reboot. Standard systemctl --user enable + enable-linger pattern. Your host comes back up without anyone signing in.
• Runs as your user, not root. Same privilege as your normal SSH session. No sudo needed for the service itself.
• Standard journal logs. journalctl --user -u scry-linux-host -f gets you the log stream like any other systemd unit.
• Clean restarts. systemctl --user restart scry-linux-host. The host re-registers with your account on its own.

What you need on the server

• A real display server (Xorg today). On a true server with zero display, you'll want Xvfb + a lightweight desktop session if you actually want to see something to control. A genuinely headless “no display anywhere” box can pair and be online but won't have anything to stream.
• ffmpeg with libx264 + libvpx. The standard Ubuntu/Debian/Fedora/Arch ffmpeg packages include both. Custom minimal builds need them re-enabled.
• .NET 8 runtime. The host is a .NET app. The install script handles this on common distros.
• Outbound HTTPS to the relay. No inbound ports, no NAT traversal config on your end. WebRTC handles the rest.

Honest caveats for the headless case

• Wayland not yet GA. If your headless server runs a Wayland session (rare today, common tomorrow), the 0.3 release is the right one to wait for — it's in test now via xdg-desktop-portal ScreenCast and libei input. Details on the Wayland page.
• Pre-login screen access is out of scope. The host can't stream the LightDM/GDM/SDDM login screen yet. Pair it after a normal user session is alive.
• No graphical tray. Status lives in the CLI and on your account on the web. A tray is follow-up work.
• Single-monitor on free. Multi-monitor is Pro and currently in preview across the platform.
• Transport-encrypted, not end-to-end. WebRTC's DTLS/SRTP. A real, named property; not the stronger end-to-end claim.

Related