ELX-AnyRemote
Remote desktop access from a browser or an app
Connect to a remote computer and take control of it: the screen arrives as video, the keyboard and mouse go back over the same encrypted connection, and files move in both directions. A nine-digit identifier is all the other side has to tell you.
The browser is enough
To watch and control a machine you need a browser. The person who is being helped installs the app; the person helping does not have to install anything at all.
Encrypted end to end
The screen travels as an encrypted media stream and the input over an encrypted data channel — the same mechanisms browsers use for video calls. The connection is negotiated through the server; the picture is not stored anywhere along the way.
A nine-digit identifier
Each installation receives a permanent number on first launch. That number, and a confirmation on the far end, is the whole of the connection procedure — there is nothing to configure on the router.
Files and clipboard
Files move in both directions over the same connection, and the clipboard is shared, so a copied path or a licence key arrives where it is needed instead of being retyped over the phone.
An address book
The machines you return to are kept by name rather than by number, with favourites for the handful you open every day.
Windows, Linux and Android
The controlling side can be any of the three, or simply a browser. The controlled side runs the desktop app, on Windows or on Linux with Wayland or X11.
Screenshots
How a session happens
- The person to be helped starts the app and reads out the nine-digit number it shows.
- You enter that number — in the browser or in your own copy of the app — and ask to connect.
- Their machine asks them to confirm. Nothing happens until they agree.
- The screen appears. Mouse and keyboard work; files and clipboard travel the same connection.
- Either side can end the session at any moment, and closing the app ends it too.
What is involved
The controlled machine
Runs the desktop app, which captures the screen and injects the incoming input. Windows, or Linux under Wayland or X11.
The controlling side
A browser, or the same app on Windows, Linux or Android. Nothing is installed to look at a screen from a browser.
The rendezvous server
Introduces the two sides to each other and helps them cross NAT. It carries the setup, not the picture, and it can be your own.
Where the two machines can reach each other directly, the media goes directly. Where a network refuses to allow that, the traffic is relayed instead — the session still works, and neither side has to know which of the two happened.
What it is for
- Helping somebody who is not technical. They read a number aloud and press one button; you do the rest.
- Reaching your own machine. The office computer from home, or the workshop machine from the office.
- Servicing equipment on site. An industrial PC behind somebody else's router, without asking their network administrator for anything.
- Moving a file to a machine you are looking at. Faster than mail, and it lands in the folder you can see.
At a glance
- Connection
- Encrypted peer-to-peer media and data channels
- Controlled side
- Windows, Linux (Wayland and X11)
- Controlling side
- Browser, Windows, Linux, Android
- Identifier
- A nine-digit number issued on first launch
- Transfers
- Files in both directions, shared clipboard
- Session limits
- None — no duration cap, no session count
- Server
- Rendezvous and relay; can be self-hosted
- Built with
- Go on the server, Flutter in the client