My Development Setup: Remote VM Edition

I’ve been refining my development environment over the years, and I’ve landed on a setup that works really well for me: a Proxmox server in my homelab with development VMs that I access remotely from my Mac Studio and MacBook.

The Stack

At the core of my setup is a development server running Proxmox in my homelab. On it, I have a development VM that serves as my primary development environment. The key to this setup is that the VM is fully reproducible. I use Ansible to provision it from scratch, which means I can rebuild it anytime without worrying about losing my configuration.

For daily work, I connect remotely from either my Mac Studio (when I’m at my desk) or my MacBook (when I’m on the go).

Why This Approach?

Consistent Environment

Having a dedicated development VM means I have the same environment regardless of which machine I’m using to connect. Whether I’m on my Mac Studio or MacBook, I’m always working in the exact same setup. No more starting work on one device and not being able to access it on the other one because I didn’t git push it yet.

Reproducibility

This is where Ansible really shines. Everything about the VM’s configuration is captured in code. If something breaks or I need to upgrade, I can spin up a fresh VM and have it configured exactly how I want it in minutes. Dependencies, tools, environment variables, dotfiles—all automated.

It’s also great for experimentation. I can clone the VM, try something risky, and if it doesn’t work out, just delete it and move on. No hours spent trying to undo changes.

Resource Management

The Mac Studio and MacBook stay clean and performant because I’m not running resource-intensive builds and development tools locally. The heavy lifting happens on the Proxmox server, which has dedicated resources for development work.

This also means better battery life on the MacBook. Remote development uses far less power than running Docker containers, language servers, and compilation jobs locally.

Flexibility

Proxmox makes it easy to adjust resources as needed. Need more RAM for a particular project? Shut down the VM, bump up the allocation, and boot it back up. Want to test something on a different Linux distribution? Spin up another VM alongside the main one.

The Remote Development Experience

Remote development has come a long way. With tools like VS Code’s Remote SSH extension, the experience is nearly indistinguishable from local development. The editor feels responsive, terminal commands execute quickly, and file operations are snappy enough that I don’t think about the fact that I’m working on a remote machine.

The main requirement is a decent network connection. At home I have a 10G ethernet connection to my VM. Even when I’m traveling, hotel wifi or a phone hotspot is usually sufficient for comfortable remote work. Starlink even makes it possible to working when camping!

Backup and Disaster Recovery

Since the development environment lives on the Proxmox server, backups are centralized. I take regular snapshots of the VM, and because the configuration is in Ansible, I have both the state and the recipe to recreate it.

If my laptop dies or gets lost, I just connect from another machine and pick up exactly where I left off.

Trade-offs

This setup isn’t for everyone. There are some downsides:

  • Network dependency: No network means no development. Offline work requires a local fallback environment.
  • Initial complexity: Setting up Proxmox and configuring Ansible playbooks takes time upfront.
  • Hardware investment: Running a homelab server means additional hardware, power consumption, and maintenance.
  • E2E testing challenges: Running end-to-end tests in headed mode isn’t as seamless.

But for my workflow, these trade-offs are worth it.

Final Thoughts

Having a reproducible, centralized development environment has been liberating. I spend less time worrying about configuration drift between machines and more time actually building things. The ability to recreate my entire dev environment from scratch with Ansible gives me confidence to experiment without fear of breaking something permanently.

If you’re comfortable with infrastructure-as-code and have (or are considering) a homelab, I’d highly recommend giving this approach a try! The initial setup cost is quickly offset by the convenience and peace of mind it provides.