Guide

How Much Memory Should You Give a Linux VM on a Mac?

This isn't the LLM question; that's covered separately, and it's different because a model's footprint can be calculated. Dev, build and CI workloads can't be, so here's how to size for them anyway, and what happens to memory the guest isn't using.

By Gaoliang Luo · Published September 22, 2026 · Updated September 28, 20262 min read

The framework's allowed range isn't a recommendation

Velo Workspaces keeps your memory request within the framework's minimumAllowedMemorySize and maximumAllowedMemorySize. That range keeps a configuration valid; it doesn't tell you what's sensible. The framework will accept more memory than your Mac can comfortably spare, and a workspace sized up to that ceiling on a Mac that also needs memory for everything else competes with it like any overcommitted process.

What the built-in profiles suggest

The built-in profiles pair memory with vCPUs, and the pairing is a useful guide: Office & Study starts at 4 GB, Code & Build at 8 GB, DevOps Lab at 12 GB, and AI Sandbox at 16 GB. They're starting points to adjust, not rules. A shell and an editor rarely need more than the Office & Study tier. A real build with a dependency-heavy install benefits from Code & Build's headroom, because compilers and linkers spike well above their steady-state use during the build itself.

The balloon: assigned doesn't mean locked away

Every Linux workspace gets a virtio memory balloon device (VZVirtioTraditionalMemoryBalloonDeviceConfiguration). It exists so that memory assigned to a VM isn't necessarily lost to the Mac for good: the hypervisor can reclaim memory the guest isn't using and hand it back when the guest needs it, with the guest kernel cooperating through its balloon driver. That's standard Linux and Virtualization framework behavior; Velo Workspaces creates the device with its defaults and doesn't add its own policy.

Don't overstate it, though. The balloon means a generously sized, mostly idle workspace doesn't starve the Mac the way a fixed allocation would, but how aggressively memory is reclaimed depends on the framework and the guest kernel. Size for the workload; the balloon isn't a reason sizing doesn't matter.

A way to size that isn't guessing

Start from the nearest profile above rather than an arbitrary number.
Watch swap inside the guest while the real work runs, not at idle. free -h or vmstat showing swap in use under load is the clearest sign a workspace is too small, far more reliable than memory that merely looks "full".
Size for the peak, not the average. A build's link step or a test suite's worst moment matters more than its steady state, the same lesson the LLM RAM post draws for a growing KV cache.
Leave the Mac real headroom. macOS and your other apps need their share of unified memory too.

A cloud image makes experimenting cheap: create a workspace, run your real workload, and if it swaps, create another with more memory a minute later.