I’m always on the lookout for solutions to improve my remote working and support capabilities and recently came across ‘Remotely‘, an open source and self-hostable remote support solution for Windows and Linux. Self-hosted and open source, hm, sounds interesting, I thought, just what I like for privacy and confidentiality reasons. So I had a closer look!
Developed by Jared Goodwin, the sources and detailed information can be found on Github. Remotely is based on a central server to which the remote device and the supporter connect. This is necessary to get around NAT limitations of the typical Internet home connection that prevents direct peer to peer communication. While a Linux/Windows program needs to be executed on the remotely supported device as in any other remote support solution, everything on the supporter side runs in the web browser. WebRTC protocol is used for remote screen, keyboard and mouse interaction. How nice!
For trying out things quickly, Jared has put a demo instance of the central server part on a cloud based server, so one can try out things very quickly. Creation of an account is required but the email address is not checked and hence does not necessarily have to be connected to anything. Once logged-in, connecting to a remote desktop session is as easy as clicking on the ‘Remote Control’ button in the web browser and typing in the 9 digit support code that was generated by the remote support application that was started on the client side.
When I tried this out, I was a bit disappointed at first, because reaction to mouse and keyboard input and changes on the remote screen in the browser was very slow with a delay of at least 3 seconds. In other words, hardly usable. I quickly found out, however, that the reason for this was that I and my test-VM running Windows were in Europe, while Jared’s server was in the US and had a round trip time of 400 ms across the Atlantic. That makes it 800 ms in total when the supporter and the supported device is in Europe.
But using the demo server was not what I had in mind anyway, I wanted my own server instance. The configuration procedure looks a bit daunting, but the project provides a ready to use Docker image on Docker Hub and a docker-compose.yml file. So I launched a new Ubuntu 20.04 VM in the cloud of my preferred hosting company in Germany and started a new Remotely server Docker container. This took me less than 5 minutes. Perfect! While the Docker image is rather large at 500 MB, running the Remotely server ‘only’ takes less than 150 MB of RAM.
On the client side, the support executable can then be downloaded from this server. Afterwards, one thing that has to be done by hand is to change the web server details in the settings of the client program, as it points to the demo instance per default. Perhaps that is something to be improved for the Docker image in the future. The supporter also connects to the central server and has to create an initial account. The first account created automatically receives administrator rights and further account creation on the server is automatically blocked. In other words, the private instance remains private unless opened again.
It’s also possible to install a permanent client service on a device that then enables remote access to the device without a pass-code. Also, the device appears in a device list on the server and basic health parameters such as processor load, RAM utilization and remaining disk space are shown. When I first tried this, my Windows 10 client running in a virtual machine on Virtualbox in ‘headless mode’ would disconnect every very minutes. This is only a bit annoying with the background service running, as it automatically reconnects, but it’s a major problem in Desktop support mode, as the user has to frequently send a new code to the supporter. Whether this is an issue on the supporter side, the server, or on the client is not quite clear to me at this point. I will have to try this on a physical Windows 10 machine at some point, as this is the second use case I have in mind.
Another thing I noticed when using the solution is, that probably due to the use of WebRTC screen sharing, the remote screen is typically refreshed in low resolution at first, while the full resolution of the part of the screen that has changed only appears a few seconds later. That’s not a problem for a remote support scenario, but it’s not well suited for working on a remote physical or virtual computer for a longer time. Also, while the German keyboard layout is supported, special assignments such as the @ character, which is ALT-GR+Q on the German keyboard, do not make it to the other side.
Overall, I very much like this approach and I have a number of use cases in mind for which I want to use it in the future. The major thing that needs to be fixed, however, are the frequent disconnects I suffer when I remotely use a Windows 10 installation in a virtual machine. In a follow up post I will have a look at whether the disconnects disappear on a physical device running Windows 10 as supported device, and if I can run the Remotely server behind my default reverse proxy setup I use for my other ‘dockerized’ services.