Developing inside a virtual machine

Original Article ↗ Hacker News Discussion ↗

Developers weigh the trade-offs between doing all their work inside virtual machines, running code in Docker-based “devcontainers,” or relying on tools like WSL and remote SSH environments. Many value VMs and containers for reproducible, isolated setups that protect the host machine and simplify sharing configs, but they also report friction around performance (especially on macOS/Windows), USB and GPU passthrough, VPN/proxy quirks, and corporate security tooling. Overall, the trend is toward remote or virtualized development environments that centralize dependencies and tooling while letting the editor run locally or in a browser.

Dev Containers vs. Full VMs

  • Many praise VS Code Dev Containers and similar setups: per-repo images, reproducible environments, easy sharing, and alignment with production containers.
  • Others report quirks, especially on Windows/WSL: containers freezing, Docker restarts, memory sensitivity, and performance issues on Docker Desktop/macOS.
  • Some prefer VMs plus Docker inside the VM: closer to Linux semantics than Docker-on-macOS, often faster for I/O-heavy workloads and databases.
  • Debate over whether a VM is necessary if you’re mostly terminal-based; some argue containers should suffice, others note macOS requires a VM for Docker anyway.

VS Code Remote & Remote Dev

  • Strong support for VS Code Remote SSH: better latency and file watching than shared folders, language servers run on the remote, offloading CPU/RAM from the host.
  • Some use remote containers on powerful shared hosts (multi-GPU, huge RAM), giving laptop users “cloud workstations.”
  • Alternatives mentioned: running the IDE inside the VM, code-server (VS Code in browser), or SSHFS for editors without native remote support.

Hardware & Peripheral Access

  • USB/serial forwarding from host to dev environments is a pain, especially on macOS/Docker Desktop.
  • Suggested solutions: VMware USB passthrough, QEMU device forwarding, docker-compose devices on Linux, and USB/IP over network.

Corporate Networking, Proxies, and Security

  • Corporate TLS MITM (e.g., Zscaler) causes recurring pain, especially with WSL/Docker and custom trust stores; some call it effectively “malware-like” but note its audit/compliance role.
  • VPN + WSL networking is fragile, though newer WSL networking modes reportedly help.
  • Several use VMs to isolate work from personal machines or to be able to “nuke” company IP later.

Sandboxes, Dependencies, and Supply Chain Risk

  • Typos or malicious packages (e.g., in npm) drive interest in VMs and sandboxes.
  • Suggestions: bubblewrap-style syscall/filesystem isolation for node, package managers that limit install-time code execution, or full dev inside VMs.

Clipboard, UX, and GPU

  • Neat trick: use SSH from guest to host to proxy clipboard commands (pbcopy/pbpaste) with restricted authorized_keys commands.
  • GPU passthrough VMs can feel indistinguishable from bare metal, though high-resolution multi-monitor setups may demand lots of RAM with some hypervisors.

Distros, Nix, and Alternatives

  • Ubuntu widely used but criticized for upgrade friction; Debian seen as more stable for long-lived dev VMs.
  • Nix-based tools (Devbox, flox), Lima, and an open-source dev environment orchestrator (Daytona) are mentioned as lighter or more structured alternatives.