Why I Moved My Non-Apple Development Off macOS and Into a Debian VM

Asuka feels less worried as she uses Debian VM

I use my Mac for everything important: personal communication, banking, work, and iOS development. Over time, I realized I was becoming increasingly uncomfortable installing general development tooling directly on it.

The issue wasn’t any single tool. It was cumulative.

macOS does not have a native, first-party package management model comparable to Debian’s APT. Once you introduce third-party package managers, language runtimes, and build tools, the system gradually becomes harder to reason about. At some point, I noticed that I no longer felt confident explaining why everything on my machine existed.

That loss of confidence mattered more to me than convenience.

Constraints I Set

I defined a few non-negotiables:

  • macOS remains my primary, trusted system
  • iOS development (Xcode) stays on macOS
  • General development tooling should not live on the host
  • The setup must be reversible
  • Cleanup should be mechanical, not forensic

The Shape of the Solution

I moved general development into a Debian VM using UTM.

Key decisions:

  • Headless Debian (no desktop environment)
  • Full-disk encryption inside the VM
  • SSH-only access from macOS
  • VS Code used via Remote-SSH
  • Debian APT as the single package authority inside the VM
  • No Homebrew, compilers, or language runtimes on the host

The VM runs a minimal, headless Debian installation with full-disk encryption. I access it exclusively over SSH from macOS, and use VS Code via its Remote-SSH feature. From a workflow perspective, the VM behaves like a small, local server rather than a second desktop.

macOS became the interface. Debian became the workspace for any software development except iOS and macOS.

Why UTM

I chose UTM primarily because it integrates cleanly with macOS while staying out of the way.

UTM is a thin, transparent wrapper around Apple’s Hypervisor framework and QEMU. It does not introduce its own package ecosystem, background services, or opaque management layer. The VM is represented as a single, inspectable bundle on disk, which makes cloning, backing up, or deleting it straightforward and predictable.

Just as importantly, UTM supports Apple Silicon virtualization natively and allows me to run a fully supported ARM64 Debian system without emulation overhead. From a trust and maintenance perspective, it felt closer to using a system facility than adopting a third-party platform.

I wanted the VM to feel like infrastructure, not another environment to manage. UTM fit that constraint well.

Why This Works for Me

All development entropy now lives inside a single, well-defined boundary. If something feels messy, I don’t clean it. I delete the VM or return to a clean clone.

The host OS stays consistent and trustworthy. Experimentation feels safe again. I no longer need to remember what I installed or why, because recovery does not depend on memory.

This setup may not be right for everyone, but it restored a level of confidence and calm that I was no longer willing to trade away for convenience.

Leave a Reply

Your email address will not be published. Required fields are marked *