Self-hosted remote desktop

Reach any machine, from any browser. The server is yours.

A small agent on the machine you want to reach, a browser tab on your side, and an encrypted peer-to-peer stream between the two. Your server only makes the introduction.

Open the console How it deploys
Viewer
Any browser
Host agent
Windows · macOS · Linux
Transport
WebRTC, peer-to-peer
Deploy
One container

Control from WindowsmacOSLinuxChromeOSAndroidiOS nothing to install on your side

01How it works

Three steps, and the video never touches your server.

  1. A

    Install the agent

    A small host agent for Windows, macOS or Linux goes on the machine you want to reach. It gets a 9-digit device ID.

  2. B

    Share the ID, or issue a key

    For a one-off, read out the ID and the person at the machine clicks Allow. For machines nobody sits at, issue an unattended access key.

  3. C

    Connect from any browser

    Open your console, pick the device, and the session starts in a tab. Open another tab for the next machine.

02Features

The working parts.

Everything you expect from a remote desktop tool, minus the account on somebody else's cloud.

  • F-01

    The viewer is a web page

    Works in any modern browser on Windows, macOS, Linux, ChromeOS, Android and iOS. Nothing to install on the controlling side.

  • F-02

    A small host agent

    One agent for Windows, macOS and Linux on the machine being controlled. Every device gets its own 9-digit ID.

  • F-03

    Peer-to-peer WebRTC

    Encrypted video goes straight between the two machines. The server brokers the connection and steps back.

  • F-04

    Multi-session, multi-user

    Several technicians can be on one machine at once, and one technician can keep many machines open in tabs.

  • F-05

    Attended mode

    The person at the machine sees who is asking and must click Allow. No click, no session.

  • F-06

    Unattended access keys

    Scoped, time-boxed, use-limited and revocable keys for machines nobody sits at. See how keys work.

  • F-07

    Optional TURN relay

    For networks too strict for a direct path, add a relay. The stream stays encrypted end to end between the peers.

  • F-08

    Four roles

    Admin, Technician, Device owner and a read-only Auditor. See the roles.

  • F-09

    One container

    Node and SQLite in a single Docker container. No external database to run. See the deploy steps.

03Security · not in the other tools

Six things the other tools left out.

Remote access is a master key to a computer. Farhand treats it that way, for the technician and, more importantly, for the person on the other end.

01

Security code

Both sides see the same three-part code, derived from the connection's encryption fingerprints. Read it aloud. If it matches, nobody is in the middle. Not an attacker, and not even your own server.

02

Tamper-evident audit log

Every action is hash-chained to the one before it. Edit or delete a line and the chain breaks where anyone can see it.

03

Scam shield

Remote-access tools are the number one vehicle for support scams. On a first-time connection, the host gets a plain-language warning before anything else.

04

Panic key

One hotkey on the host kills every session and locks the door behind them. No menu, no asking nicely.

05

Session receipts

Device owners see who connected, when, for how long, and how they got in. Every session, not only the suspicious ones.

06

“Always ask me”

A local override on the machine itself. Switch it on and every connection needs a click from the person sitting there, whatever unattended key is presented. The human at the keyboard outranks the key.

04Access keys

Unattended access with an expiry date.

A permanent password to a machine is a liability. A Farhand key says exactly what it opens, for how long, and how many times.

  • Scoped. Full control, or view-only.
  • Time-boxed. Expires after the number of hours you choose.
  • Use-limited. Good for a set number of connections, down to a single use.
  • Revocable. Kill it the moment the job is done.
  • Stored only as a hash. The key is shown once; the server keeps a hash, never the key.

05Roles

Four roles. One of them can only watch.

  • ADM

    Admin

    Runs the server: users and roles, every device and key, and the whole audit trail.

  • TEC

    Technician

    Works the machines they have been granted. Many open in tabs, alongside other technicians.

  • USR

    Device owner

    Enrols their own machines, issues and revokes keys for them, and reads every session receipt.

  • AUD

    Auditor

    Reads devices, sessions and the audit log. Cannot open a session or change a thing.

06Deploy

One container on a small VPS.

Farhand is built for Dokploy. Node and SQLite live inside the container, so there is no database to provision and one volume to back up.

  1. Create a Compose app in Dokploy

    Point it at the Farhand repository. The compose file on the right is all of it.

  2. Set the admin login

    Fill in ADMIN_EMAIL and ADMIN_PASSWORD. Change the password from the default before you deploy.

  3. Add your domain

    Route it to port 8080. Dokploy handles HTTPS through Traefik and Let's Encrypt.

  4. Sign in and enrol a machine

    Open the console, install the host agent on your first device, and connect.

docker-compose.yml 
services:
  farhand:
    build: .
    environment:
      - ADMIN_EMAIL=you@example.com
      - ADMIN_PASSWORD=change-me
    volumes:
      - farhand-data:/data
    expose:
      - "8080"
volumes:
  farhand-data:

All state lives in farhand-data. Back up that one volume.

07Ready when your server is

Your machines. Your server. Your keys.

Open the console Deploy guide