When I started using Windows in 2014, I continued to keep my development environment on Linux. I first did this with Vagrant; then, I used WSL, Docker, WSL2. I had an idea forming in my head ever since. I’m already using two different systems on a computer simultaneously; is it possible to use one in a thin client and connect to the other remotely?

PURPOSE

Let me first start by explaining why I want to do this:

• I need a powerful computer to be able to use two systems at the same time. But, on the other hand, I would like to use a lighter computer with better screen quality and longer battery life instead of a more powerful computer.
• I already have a computer provided by the company I work for, and I don’t want to move two computers at once. And I don’t want to keep my files and hobby projects on the workstation.
• Sometimes I want to connect to my development environment from another device such as a tablet and phone. To do this, I have to keep my computer turned on all the time.

Now let’s look at where I can keep the development environment and investigate the other alternatives.

PLAN

Creating a virtual server using a VPS service like DigitalOcean or AWS Lightsail was my favourite option; however, when the need for RAM increased because of Docker, it’s possible to buy a Mac Mini every two years with the cost of VPS. So I eliminated this option.

My first thought was to make a portable PC using Raspberry Pi 4. Since I don’t have enough experience in this subject, I thought I could do it; but as the system requirements increased, there were quite a few problems, and it moved away from the structure I imagined. For example, when I added an SSD, there was a heat problem; I had to add a heatsink to solve it. In addition, it needed an adapter to meet the power, and it wasn’t easy to find an excellent case to match it.

Even though I looked for ready-made solutions later, I couldn’t find a product that I would like. So finally, when the performance achieved according to the cost did not satisfy me, I turned to other alternatives.

There’s no advantage of having a laptop for the development environment, but I wanted the device to be portable because I occasionally travel. I also thought of keeping the server machine in the same place all the time, but I wanted to be able to physically access the device in case of an emergency such as a system error or power outage.

I also looked at other alternatives such as Intel NUC and Beelink; I was disgusted with their brick-like adapters, so I preferred buying a Mac Mini because the case already includes the power supply. However, I still don’t understand why they can’t fix this adapter issue on PCs.

CONNECTION

After purchasing the machine that will provide my development environment and installing it at home, I made the first updates. First, I reviewed the power consumption settings to prevent the device from going into sleep mode.

Then I determined the programs I would use to connect to the computer. I’ll explain later why I use multiple methods and tools to connect to a device:

1. TAILSCALE: The first thing I need to know to connect the server is a fixed address of my server. I’m using TailsScale, which uses WireGuard technology for that. For example, when I set the name of my server as gerudo, I can connect it by saying ssh gerudo. The device I use as a client must also be registered in my TailScale account to find the address where gerudo is registered.
2. SSH & MOSH: The most necessary applications I used in the terminal are SSH and Mosh. Mosh prepares a more stable connection than SSH, but you need to configure your terminal to support 24-bit colours.
3. REALVNC: There is no need to install a separate VNC application for macOS, but you can see the machine’s address when you log in with the RealVNC account. But if you are using TailScale, you can connect with any VNC client by saying vnc://machine-name. I only use it when necessary.
4. DUET DISPLAY: It helps me to use my iPad as a primary or secondary display.

The server-side of the development environment is ok; now we can forget that part at home. Let’s come to the client part, which we will always have. You decide according to your situation, I will explain my preferences:

1. WORKSTATION: I can access my editor via SSH or MOSH from the computer provided by the company, and I can access the desktop with any VNC client.
2. IPAD: It’s better to use a tablet instead of carrying two laptops for me. I use the iPad to access my private files and use it as a second display for the workstation. Sometimes I don’t take my workstation, and I connect to my server using Blink from the iPad.
3. IPHONE: Although I prefer not this method, it’s cool to access the graphical interface and do small tasks on the server. I just use RealVNC.

As I said before, I use TailScale on all devices. Maybe not needed on the phone because RealVNC already knows the machine’s address via the user account.

Now let me explain why I use multiple connecting methods to the server. Don’t think that this whole structure is working smoothly; it’s not easy as it seems; there are at least a few critical problems I experienced once.

PROBLEMS

The first problem is that you need a display until you prepare your login account on Mac Mini for the first time. If I could use Raspberry Pi 4 as a server, it wouldn’t have this problem, but there is such a problem for Mac Mini, unfortunately.

The other problem is making the first internet connection when you move the server to a different place. If you use iPhone, you don’t need to worry about that because it shares connection info between the devices. But what if you don’t have an iPhone or iPad? So yes, you need a display again.

Another problem is with Duet Display. If the server restarts and you log out somehow, you need to log in again to use Duet. It is possible to solve this problem by automatic login; however, it’s creating security weaknesses, and it’s not a reasonable option. So instead, I connect with a VNC client and log in once. Then I continue with Duet Display.

Let’s talk about work-related issues a bit. I’m neither not a frontend nor a mobile developer so I can work with just a terminal. Sometimes I’m interested in game development; I plan to use Duet Display for that. If I were a frontend user, I think I could use my workstation as a client and keep the code on my server; and I would prefer to debug the code from the browser on my workstation. On the other side, I think none of what I said would work in mobile development. If you have any suggestions on that, I would love to know.

FINALLY

Due to the frequency of power and internet cuts in Turkey, adding UPS (uninterruptible power supply) to this kind of remote development environment is necessary. Apart from that, you can get paranoid and consider making a mini-robot that you can control with wifi and press the computer’s power button.