I stopped using Windows on my own PCs about two years ago. Not because I don't like Windows, I actually really like Windows 10 (keep reading), but when you're running Linux servers, it's just so much easier to run the same OS on both your development PC and your production servers. That and when you're administering servers, as you so often do when you have a homelab, you just can't beat the command line of Linux.
Now, with Intel's latest panoply of security flaws and the revocation of Intel HPET on the Linux kernel, I've been forced back onto Windows since my battery life on Ubuntu is now abysmal: I get around ~7-8.5 hours on a charge with Windows; that battery life drops to 2.5 hours on Ubuntu on the exact same brand new laptop. So kudos to the Windows kernel team. There's something to be said for paid developers.
Being back on Windows, I am quickly reacquainted with all of the things I missed about Windows. I now have Launchy back. I used Albert on Ubuntu, but he's no Launchy. On Windows, I also have access to all of the "creative" applications only available to "mainstream" consumer OSes, specifically the Adobe suite of products. I don't currently know too much about graphic design, but I've decided that its a key skill for the developers of the future and as such I will be teaching it to myself this year. And then there's PuTTY- oh how I've missed PuTTY. I love its ability to save connection settings, but what I've missed most of all is that, in PuTTY, simply highlighting a row of text copies it to the clipboard. None of that separately right-clicking-to-copy-from-the-drop-down-menu or accidentally-using-the-wrong-shortcut-key-comb-and-sending-a-break-command-to-the-terminal mess. Yes, I know, PuTTY is also available for Linux but you just don't have the same need for it in Linux where a quick launch of the terminal puts you right into SSH.
So now that I am on Windows, while all of my servers run Linux, I find myself in the Operation Market Garden of DevOps. I feel as though I am on the wrong side of the bridge (if you don't get the reference, check out the movie A Bridge Too Far).
Maybe you find yourself in the same boat. Or maybe you haven't been forced back onto Windows, maybe that's just what your laptop came with, maybe that's what your work uses, or maybe you just genuinely like Windows.
Wouldn't it be great if you could get the best of both worlds where you could keep your Windows desktop but still develop in Linux for Linux? That is the purpose of the remote development server.
What Is a Remote Development Server?
A remote development server, as the name implies, is just a server (typically a VM) whose sole purpose is for remote development. I know, I've basically given a circular reference definition, but that's because a remote development server really is just that simple. It's just a shell VM that can be used to store works-in-progress and run them remotely. Best of all, most IDEs support them.
What Are the Advantages of Remote Development Servers?
- Develop In A Different OS: For me, the biggest advantage is that it allows me to develop in the same OS as my production servers, but without having to use that same OS on my local PC.
- Run Time-Consuming Tasks: For the data scientists/machine learning guys, yall are already familiar with this. I doubt you want to train your models on your laptop. Even if it's a simple-enough model and could be done reasonably enough with a laptop dGPU, I hope you have a full battery and it can be done in an hour. Remote development servers allow you to run time-consuming tasks because the server persists even when you're not directly connected to it.
- Superior Hardware: My laptop has an i7-9750H with 6 cores/12 threads. It's pretty good, but a laptop will never compare to a Xeon or Threadripper. Need more RAM? Just up the allocated RAM on the VM.
- Rapid Demo/Prototype Environment/Public Localhost: When I am out and about, chances are that I don't control the network I'm connected to, which means that when I want to demo something, it's not exactly easy. My remote development server on the other hand is a VM that sits in my homelab. A homelab with a network I control. When I want to demo something I just flip a switch on my NGINX reverse proxy and forward the requests onto my remote development server. Super easy and super convenient.
- Reliability: Just by virtue of having a fixed device on a network, automated backups are just easier. (P.S. I recommend unRAID for the backup location).
- Etc.: There's a lot more, but I would like for you to actually finish this article, so let's move on to setting up the remote development server itself.
Setting Up the Remote Development Server:
1. Deploy an Ubuntu VM
Hopefully, I won't catch too much flak for this, but the purpose of this guide is for deploying a remote development server, not "how to set up a VM". Additionally, the way you deploy a VM varies based on your virtualization host (ESXi or Proxmox) or maybe you're not self-hosting and you want to use a service like Digital Ocean. Besides, I assume if you're reading a guide like this, you already know how to set up a VM.
Feel free to let me know if I am off base here and you need help in the comments/forums.
That being said, I probably will do a brief guide in the future on my typical VM configuration in Proxmox. Heck, I'll probably also do one on setting up a Raspberry Pi as a remote development server.
Install Essential Services
2. Install SSH:
sudo apt install openssh-server
3. Install tmux:
sudo apt install tmux
tmux is a "terminal multiplexer". Essentially, it allows you to create multiple terminal sessions and therefore run multiple terminal programs at once. Most importantly of all, tmux allows you to detach from a session and keep it running in the background.
Have you ever been at the airport, SSH'd into your server to do something thinking that it will only take a moment, kick off the program, and then realized it was going to take significantly longer right as you're called to board? Or maybe your laptop's battery is just dying? If you lose connection, whatever you were running goes with it. This can leave you in a very bad way.
Well, with tmux you no longer have to worry about that.
And that's really it.
This guide is meant to be a living guide and as such, you can expect to see more updates to it as my remote development workflow progresses and I make additional refinements to my remote development server. Additionally, I will be adding IDE-specific guides for connecting your IDE to your remote development server.
As always, leave any feedback/questions in the comments below!