Multipass: Canonical's Ubuntu VM manager for Linux, Windows and macOS

The problem Multipass solves for developers who need a clean Ubuntu box

Setting up a Linux virtual machine by hand is a sequence of small decisions: which hypervisor, which image, how much disk, how to get a shell, how to keep the image patched. Multipass collapses that into a command line tool that fetches Ubuntu images itself and keeps them up to date. The README describes it as "a lightweight VM manager for Linux, Windows and macOS" designed for developers who want a fresh Ubuntu environment with a single command.

The audience is narrow on purpose. If your work happens on Ubuntu and you need a second Ubuntu to test against, or you want to rehearse a cloud-init configuration before it touches a real cloud, Multipass is built for that case. The README states that because it supports cloud-init metadata, you can simulate a small cloud deployment on a laptop or workstation. That is the strongest argument for it: the same metadata format you would feed a cloud instance is accepted locally, so the gap between a laptop test and a cloud run narrows.

How Multipass picks a hypervisor and hands you an Ubuntu instance

The architecture is a manager process plus a platform-specific driver. On Linux the driver is KVM, on Windows it is Hyper-V, and on macOS it is QEMU. The README also notes that VirtualBox can be used on Windows and macOS as an alternative backend. That choice is not something the user makes per launch in the basic workflow; the tool selects a backend for the platform, and the driver documentation is where Canonical explains backend support and system requirements.

The data flow is simple to reason about. You ask for an image, Multipass resolves it from its image catalogue, starts a VM through the driver, and then exposes the instance through the same CLI verbs regardless of backend. A cloud-init payload, when you supply one, is consumed at first boot the way a cloud provider would consume it. Instance state lives outside the VM: the CLI can list, inspect, stop, delete and purge instances, so lifecycle management is a separate concern from what runs inside the guest.

The consequence of this design is that Multipass hides the hypervisor almost completely. That is the point, but it also means the failure modes you hit are usually driver-level ones, and diagnosing them requires reading the driver documentation rather than tuning a hypervisor you configured yourself.

Installing Multipass and launching a first Ubuntu instance

On Linux, Multipass ships as a snap. The README gives this as the install command:

sudo snap install multipass

After that, the first useful command is to see which images the tool knows about. The README lists `multipass find` for finding available images, and the output is the catalogue you choose from.

multipass find

Launching the current Ubuntu LTS is a single command. The README's task table maps `multipass launch lts` to exactly that:

multipass launch lts

Once the instance is running, `multipass list` shows existing instances and `multipass shell <instance-name>` connects you to one. To run something without an interactive session, the README documents the exec form with a double dash separating the instance name from the command:

multipass exec <instance-name> -- <command>

Cleanup is two steps rather than one. `multipass delete <instance-name>` marks the instance for removal, and `multipass purge` actually reclaims it. Skipping the purge leaves deleted instances on disk.

On macOS and Windows the README points to installers on the GitHub releases page. Homebrew is available as a cask with `brew install --cask multipass`, but the README is explicit that this route is not officially supported because it is maintained by the community rather than the Multipass team. On macOS, the README also warns that you may need to disable the firewall to launch an instance successfully, and that some sudo operations during installation may prompt for your password.

Where Multipass stops being the right tool

The supported surface is narrower than the feature list suggests. The README says plainly that only the official installers are supported, which puts the Homebrew cask, community Terraform providers, the MCP server and the VS Code extensions outside Canonical's support boundary. Those integrations are real and listed in the README, but they are community-led, and a bug in one of them is not a Multipass bug.

The guest is Ubuntu. Nothing in the README describes running Fedora, Debian or Windows inside a Multipass instance, so if your test matrix spans distributions, Multipass only covers one column of it. For multi-distribution work you would be reaching for a general hypervisor or a tool with a wider image catalogue.

The macOS firewall warning is a genuine operational constraint rather than a footnote. A tool that may require disabling the firewall to launch an instance is a poor fit for a locked-down corporate laptop, and that limitation is documented by the project itself.

Finally, the licence is GPL-3.0. Multipass is not a library you link into a proprietary product; it is an application you run. Teams that want to embed VM orchestration inside a closed-source tool need to read the licence terms rather than assume the CLI's permissive feel extends to the code.

Multipass compared with running Vagrant or a plain hypervisor

The closest comparison is Vagrant. Vagrant is provider-agnostic and driven by a Vagrantfile that describes boxes, provisioning and networking; it will happily manage VirtualBox, VMware, Hyper-V and cloud providers, and it expects you to write and keep that configuration. Multipass inverts the emphasis: there is no project file to author for the basic case, the image catalogue is Ubuntu, and the backend is chosen for the platform rather than declared by you. If you want a reproducible, version-controlled machine definition, Vagrant's model is the more natural fit. If you want a shell on a fresh Ubuntu in the time it takes to type one command, Multipass is the shorter path.

Against a plain hypervisor such as VirtualBox or QEMU used directly, the difference is the management layer. Multipass adds image fetching, image updates and a uniform CLI across three operating systems, at the cost of control over the VM definition. You are trading configurability for consistency, and that trade is only worth making when Ubuntu is the target you actually care about.

The Terraform providers listed in the README sit in a third position: they let Multipass instances be described declaratively, which recovers some of what Vagrant offers, but they are community-maintained and therefore outside the supported set.

Maintenance, upgrades and what the licence means in practice

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent enough to suggest a maintained release cadence: v1.16.4 on 2026-09-08, v1.16.3 on 2026-05-26, and a release candidate v1.16.3-rc2 on 2026-05-20. The presence of release candidates before a stable tag is a signal that changes are staged rather than pushed straight to users.

Upgrade cost depends on the install channel. On Linux, the snap updates through the snap mechanism. On macOS and Windows, the README directs users to installers on the GitHub releases page, so upgrades follow whatever process those installers use. The README does not document rollback for any channel, so a team that needs to pin a version and revert should verify that behaviour before standardising on Multipass.

Building from source is a separate undertaking. The repository carries BUILD.linux.md, BUILD.macOS.md and BUILD.windows.md, and the README notes that the build system will try to use mold or lld instead of the default linker when CMake 3.29 or newer is present. That override is controlled through CMAKE_LINKER_TYPE at the CMake configure step. Contributors are expected to read CONTRIBUTING.md and GUIDELINES.md before opening a pull request.

The licence is GPL-3.0, stated in the README and in the LICENSE file. That is a copyleft licence, and it governs the code in the repository. Anyone planning to redistribute Multipass, or to build a product around modified Multipass code, should read the licence itself rather than rely on a summary; this article is not legal advice.

Editorial conclusion

Multipass fits developers who want a throwaway Ubuntu machine on a laptop and are happy to stay inside Canonical's supported installers. It is the wrong tool if you need a persistent, hand-tuned VM, a non-Ubuntu guest, or a hypervisor configuration you control directly, since the driver layer chooses KVM, Hyper-V, QEMU or VirtualBox for you. Before adopting it, check the driver documentation for your platform's backend and system requirements, and confirm whether your machine can run the backend Multipass selects; on macOS the README also warns that the firewall may need to be disabled for a launch to succeed.

Frequently asked questions

Official sources

1. canonical/multipass on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases