Now that I’ve spent a long time with different flavors of Linux over the course of my distro-hopping journey, I’ve started to gravitate towards certain distributions for my DIY projects. For example, I adore NixOS and Qubes OS for their quirky, yet highly-useful collection of features, while Alpine Linux is my distro of choice when running VMs on a low-power PVE node. I also love Debian due to its stable nature and solid compatibility, and it’s the distro that powers my automation and home server projects.

Then there’s Arch Linux, which lies on the other end of the beginner-friendly spectrum. While it does have a learning curve and lower stability, I’ve been using Arch for my Linux-based dev environments for the last couple of months – so much so that it currently houses most of my project files. The catch? I run it as a virtual machine to get rid of most of the drawbacks plaguing a standard bare-metal Arch setup.

Arch Linux serves as an amazing dev machine

Its barebones nature and AUR package collection are a part of the charm

While I appreciate the beginner-friendly design of Debian derivatives and Fedora distros, the minimalist aesthetics of Arch Linux let me tweak practically every aspect of the OS to my liking. Sure, my first couple of weeks were full of “gotcha” moments, and I had to spend more time than I’d like to admit getting accustomed to the distro’s quirks. However, my current Arch instance houses only those tools that I’ve hand-picked for my coding projects.

Plus, Arch Linux serves as an experimentation ground for my programming experiments, and it’s all thanks to the massive AUR repository. On Debian and other typical distributions, I’d have to manually add the repositories for obscure packages. But with Arch supporting the thousands of community-maintained packages on AUR, I only need to run a single command to configure them on my dev environment. Throw in the fact that its bleeding-edge nature brings the latest versions of essential packages, frameworks, and libraries as soon as they’re released, and you can see why it earns so many brownie points.

But I always run Arch inside a VM

A bare-metal Arch Linux setup can be hard to maintain

Let me preface this section by adding that Arch Linux is somewhat easier to use than you might think. Sure, it’s not ideal for beginners and needs a little bit of troubleshooting know-how. But once you get past the initial installation wizard, tinkering with the OS isn’t as difficult, especially with the highly-documented ArchWiki. And when you know what you’re doing, Arch can play nice with typical developer-centric workflows… at least for the most part.

However, when you’re relying on multiple experimental packages for your development needs like I do, things can go haywire really quickly. One dependency issue is all it takes to break multiple packages, and before you know it, you’re on your way to troubleshooting something as seemingly unrelated as networking drivers. Yes, I speak from experience.

Even leaving aside the inconveniences of a dual-boot setup, I’d always be afraid of breaking the OS with my tinkering experiments if I were to install it on my daily driver. Sure, I could learn a lot of lessons about troubleshooting when things eventually go wrong, but I can get a similar experience with a VM-based Arch setup, without the extra headache.

Snapshots and backups make troubleshooting a cakewalk

Besides running everything in a safe, isolated environment, my Arch Linux VM removes the extra complexity from maintaining the distro for my development needs. I’ve run into some weird bugs on a bare-metal setup, and while they were easy to fix thanks to forum posts, I’d rather not fight the underlying distro when I’ve already been backed into a corner because of the nightmare fuel called JavaScript coding.

Creating snapshots of virtual machines is way easier than backing up specific files from a bare-metal distro – especially when you run your VMs on something as convenient as Proxmox like I do. Heck, I’ve recovered my Arch instance to a stable state using old snapshots a couple of times over the last couple of months simply because I didn’t want to waste more time troubleshooting dependency issues or faulty packages.

An Arch VM is my preferred method, but a bare-metal instance has its perks

So far, I’ve only covered the perks of deploying Arch in a virtualized environment. But I can’t call this article complete if I didn’t admit the benefits of a bare-metal installation. Since I’ve got a couple of spare graphics cards in my home lab, I can just slot them into my main PVE server and use GPU passthrough for demanding workloads. However, on a typical Type-2 hypervisor (or even a cheap PVE node), you’ll have a hard time running GPU-heavy tasks on the Arch VM, making a bare-metal instance superior in this case.

Likewise, performance is going to be an issue with a virtualized setup, as the underlying hypervisor, distro, and management tools will siphon some resources from the PC. That said, I’m satisfied with my VM-based Arch dev machine, and it’s low-key the only way I’ll ever use this bleeding-edge distro.