Running Linux on an Apple silicon Mac

Why you need Linux at all

macOS is a Unix, which misleads people into thinking it is close enough. For hosting it isn't. There is no systemd, the filesystem is laid out differently, the networking primitives differ, and the package ecosystem has drifted a long way from anything your deployment target runs.

Nearly every deployment guide, container image and install script you will find was written for Linux. Running macOS as your server means translating all of that, forever, on your own. Running Linux on the Mac means you follow the instructions as written.

Option one: a Linux virtual machine

A VM gives you a real Linux kernel with its own filesystem, services and network stack, virtualised on Apple's own framework so the overhead stays small on M-series hardware.

This is the option that behaves like a server. You get a machine you can SSH into, install packages on, and break without consequence to macOS. Tools that do it include Lima, UTM, Tart and Parallels; MacServe uses Apple's framework directly.

The cost is memory, and it is worth being precise about it. Memory you assign to a VM is reserved: macOS no longer has it, whether Linux is using it or not.

The memory arithmetic, done properly

Start from the total, subtract what macOS needs, and assign what is left. Not the other way round. macOS itself wants roughly 4 GiB before you have opened anything, and more if you actually use the machine.

1. Write down the total memory in the Mac.
2. Subtract 4 GiB for macOS, or 6 to 8 if you also work on this machine.
3. Assign most of what remains to Linux, and keep a little back. Memory you assign is reserved whether Linux uses it or not.
4. Raise it later once you know what the workload actually wants. Starting small and growing is much easier than the reverse.

• 8 GiB MacAssign 2 to 3 GiB and expect to be careful. Enough for a small site or an API, not enough for a database plus anything else. This is the size where a VM genuinely competes with containers for space.
• 16 GiB MacAssign 4 to 8 GiB. The comfortable size: a database, a web server and a couple of services, with macOS still usable as a desktop.
• 32 GiB or moreAssign 8 to 16 GiB and stop thinking about it. Beyond that you are buying headroom for a specific workload rather than for hosting.

The disk is not the same shape as your Mac's

A VM's disk is usually a sparse image: a file on your Mac that grows as Linux writes, but only up to the size fixed when the server was created. It takes up what has actually been written, not the full size, which is why df inside Linux and disk usage on the Mac disagree and both are right.

Two consequences. Growing it later is possible but fiddly, so pick a size with room. And nothing on the Mac is mounted inside it by default, so an external drive does not extend it, and your Documents folder is not in there.

That isolation is the point. A Linux server that cannot see your files is a Linux server that cannot lose them.

Option two: Docker, and what it is doing underneath

Docker Desktop on a Mac does not run containers natively. It starts a Linux virtual machine and runs them inside it. You are already paying for the VM, you just cannot see it, and what you get on top is a container-shaped interface rather than a machine you can log into.

For packaging an application that is a fine trade. For hosting it can be an awkward one, because you end up managing a fleet of containers through a layer that hides the Linux system underneath at exactly the moments you need to see it.

There is also an architecture trap. Your Mac is arm64, and an image built for amd64 will either refuse to run or run under emulation at a fraction of the speed. Check the image before concluding that Apple silicon is slow.

docker image inspect --format '{{.Architecture}}' your-image:tag

Option three: Asahi Linux on the bare metal

Asahi is the project reverse-engineering Apple silicon well enough to run Linux directly on it, with no macOS underneath. The results are impressive and the pace is fast.

As of September 2026 it supports the M1 and M2 families, and M3 support has been merged into the installer. M4 machines boot further than they used to but remain early bring-up, with no installer. Check the project's own feature-support pages before you plan around any of this.

The bigger consideration is that installing it means partitioning the machine and giving up macOS on that partition. For a Mac whose only job is to be a server, that can be a good trade. For the laptop you also use, it rarely is.

Asahi Linux: which hardware is supported ↗

Which one to pick

Answer one question: do you want a machine, or do you want a place to run an image?

• You want a server you can SSH intoA virtual machine. It is the only option of the three that gives you a normal Linux host while leaving macOS exactly as it was.
• You want to run a packaged applicationDocker, accepting that there is a VM under it either way and that you are managing containers rather than a system.
• The Mac has no other job and you want every cycleAsahi, if your model is supported. Check first; the support matrix decides this, not preference.

What MacServe runs, and why

MacServe runs a Linux virtual machine on Apple's virtualisation framework. It was the only option that gives you a normal Linux server while leaving macOS exactly as it was. Your files are not shared into it, and you reach it over SSH like any other host.

Its disk is a sparse image on your Mac's internal SSD, 40 GiB by default, and you choose how much CPU and memory Linux may use when the server is created, which you can change later.

The caveat is the one every VM shares. Memory you assign to Linux is memory macOS no longer has. Start smaller than you think you need and raise it once you know what the workload actually wants.