It’s 2018. Why are we still developing on desktops?
In late 2017, I spent a solid grand to overhaul my work/gaming desktop. My trusty Intel i5 2500K was chugging along just fine, but it was showing its age when doing anything development, with Slack regularly using way more RAM than a chat app should, my 8GB RAM just wasn’t enough anymore.
I don’t regret this investment in the least—I’m running lots of development tasks faster than ever—but it got me thinking about the vital importance we place on our primary computing machines, from laptops to desktops. With so much power in the cloud, why do we rely so heavily on traditionally unreliable (and expensive) hardware?
Why does remote development make sense?
Remote development has some unexpected benefits that you might not have thought of. It’s not equivalent to merely translating your local machine into the cloud.
Your development is not reliant on your hardware. There’s few things more tedious than getting your development environment running, only to have something crash, forcing you to reboot and repeat the process all over again. With a remote server, you can reboot your local machine, or even switch to another one entirely, and your development environment is there waiting for you. This even applies to more extreme situations, like a hard drive failure or theft.
Your development isn’t limited by the speed of the device you’re using. Because your code runs remotely, you can use slower devices like an iPad, a Chromebook, or even your smartphone. Or, maybe more practically, your in-law’s decade-old Dell while you’re visiting over Christmas.
It’s an excellent way to learn more about Linux. These days, you can pretty easily get terminals and command line (CLI) tools on Windows and OS X, but there’s a good chance that your web app or site will eventually run on a Linux-based server. The earlier you learn about Linux administration, the better, and even setting up a proper dev environment can be an intensive learning experience in and of itself.
Easily share your dev environment with others. Instead of trying to figure out how to route your
localhost to the internet (which is inherently insecure), you can share your dev server’s
Cloud hardware is cheaper than your desktop (and especially your laptop). I just spent $1,000 on a Ryzen 1600, 16GB of DDR4 RAM, a motherboard, and a few other things. Or, for $[price]/mo, I could get a 16GB RAM server from SSD Nodes, which is powered by four cores of Intel E5 server-grade processors, and incredibly fast SSD storage in a RAID 10 configuration. On top of that, cloud hardware just keeps getting better as continue to improve our infrastructure. That’s a lot of power for a minimal investment.
Now, why doesn’t remote development make sense?
It wouldn’t be fair to pretend that remote development is some panacea—there are some trade-offs to the low cost and improved flexibility.
There’s going to be latency. Because even typing a few keystrokes into the terminal requires transferring data via the internet, you’ll likely notice a hiccup here and there. That is particularly true if you’re using something like
sshfs to edit files.
No GUIs allowed. Because your remote server is terminal-only (at least without significant effort), you’ll be “stuck” with CLI programs. If you depend heavily on some GUI application, you might experience a higher learning curve in transitioning to CLI.
You need an internet connection at all times.
Setting up your remote dev environment
Now that we’ve talked about the pros and cons, it’s time to get started, and it all begins with a server. I recommend getting as much RAM as you can afford. We’ve priced our 16GB RAM servers at $[price]/mo, which is the best value in the entire VPS market right now.
Once you have a server running, the very first thing you’ll want to do is get SSH working. I heartily recommend using SSH public keys, as they will make logging in easier and improve security at the same time.
For those who don’t know how to do this, check out our guide to getting started with SSH and public keys. This guide also includes information on how to create a non-root user and give them
Install some base applications
Any development environment is only as good as the applications at its foundation. Here are some I think are critical to said foundation.
vim: You’ll need a reliable editor to make changes to files on your server, and
vim is the go-to choice. It’s a little tricky to learn, but mastering it puts a ton of power at your fingertips.
mosh: This program is like SSH on steroids—it “allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.” You log in using the same credentials as SSH (whether a password or public key), and mosh will effectively remove the latency issue I mentioned above.
tmux: This program allows you to split your remote terminal into multiple tabs and panes, and it maintains your session even if you log off. Get started with
tmux by installing it with your package manager,
apt-get install tmux (Ubuntu/Debian) or
yum install tmux (CentOS), and then check out our getting started with tmux guide for more information on the keyboard shortcuts.
Docker: By containerizing your development, you’ll keep your base installation clean and prevent conflicts. If you need a WordPress blog to test, you can roll one in 30 seconds and then destroy it when you’re done. How you configure Docker is up to you, but we do have a guide to installing and taking your first steps with Docker on your VPS.
Customize your command line
If you have some dotfiles, now is an excellent time to install them—this way, you can instantly replicate your local development environment on the remote server.
If you don’t, one way to get started is by installing
zsh, an alternative to
bash with more customization and flexibility, followed by Oh My Zsh!. We have a guide to doing both of these things, plus others, right here on the blog.
With these tools and resources (and a great value server from SSD Nodes!), you’re well on your way to having a productive, effectively remote development environment. But this is just the first step—there’s so much more to explore.
We develop on desktops because it’s easy, and because that’s how we’ve done it for decades. But now, at least, you have another option available to you. Happy (remote) developing!
[cta text=”Better remote development with the best value in cloud hosting.” text2=”Get 6x RAM per dollar compared to Vultr and more than 1GB/s I/O for faster, more efficient coding, continuous improvement, and deployment tasks.” button=”Start developing in the cloud”]