Local Cloud Simulation with Multipass

[cniederberger]

Multipass has long been the easiest way to launch and manage Ubuntu virtual machines on Linux, macOS, and Windows. Whether you’re developing cross-platform software, testing distributed systems, or experimenting with cloud technologies, Multipass provides a fast and consistent way to create Ubuntu environments with just a few commands.

With the upcoming release of Multipass 1.17, we’re taking another step in the project’s evolution towards a local cloud simulation environment.

What’s new in Multipass 1.17

Multipass 1.16 marked an important milestone by making the entire project fully open source. The proprietary components previously required for Windows and macOS were moved into the main repository, and the documentation was migrated to Read the Docs. Since then, we’ve been working on the next feature release, and we’re excited to offer a preview of what’s coming in Multipass 1.17.

Direct support for Debian and Fedora

Building on the custom image support introduced in the previous release, Multipass 1.17 adds direct support for additional Linux distributions, including Debian and Fedora. Yes, we open the door to let our users enjoy selected distributions other than Ubuntu and benefit from the respective variants as new playgrounds. At the same time, the various appliances - also known as blueprints - will be removed as announced.

Availability Zones (AZs)

Our long-term goal is to evolve Multipass into a local cloud sandbox. A major step in that direction is the introduction of Availability Zones (AZs). Users can assign virtual machines to Availability Zones and simulate zone failures to verify redundancy measures, validate high-availability implementations, and reproduce cloud deployment scenarios—all on a local machine.

Virtualization backend updates

We’re also continuing to simplify and modernise the supported virtualization backends by focusing on native platform technologies. On macOS, Multipass introduces support for the Apple Virtualization Framework (AppleVZ), while the Hyper-V backend has been reworked to use native Windows APIs. This also enables Multipass to run on Windows Home Edition. At the same time, LXD and libvirt have been removed as backends, while VirtualBox (Windows and macOS) and QEMU (macOS) are now deprecated.

The vision for Multipass

Multipass began as a simple way to launch Ubuntu virtual machines and provide an easy gateway into the Ubuntu ecosystem on any platform. Since then, it has steadily evolved, and our vision today is to transform it into a comprehensive local cloud sandbox: a self-contained environment where developers can simulate, prototype, and learn cloud-native technologies without requiring access to a public cloud or incurring cloud costs.

Our goal is to provide a rich platform for local experimentation that enables developers and operators to explore cloud technologies in an isolated, reproducible environment.

Looking ahead

As Multipass continues to evolve, we’re exploring several new capabilities alongside foundational improvements.

Beyond Availability Zones, we’re investigating additional storage capabilities. Block storage would allow persistent volumes to be attached to instances, while blob storage support would make it easier to work with unstructured binary data. Together, these features would enable new workflows for applications with more advanced storage requirements.

We’re also continuing to simplify our hypervisor support by moving towards a single native backend on each supported platform. This will allow us to focus our efforts on performance, security, maintainability, and a seamless user experience.

The Multipass GUI will continue to evolve with additional functionality and visual improvements. We’re also exploring support for VSOCK, which provides a fast and secure communication channel between the host and guest without requiring network connectivity.

Across the project, quality and security remain central priorities. We’re continuously improving our continuous integration pipelines and expanding our end-to-end test coverage to ensure Multipass remains reliable as it grows.

Try Multipass today

If you haven’t explored Multipass yet, now is a great time to get started. You can install it on your platform of choice and launch your first Ubuntu virtual machine in seconds.

Multipass is fully open source, and contributions from the community are always welcome. Whether you’d like to report a bug, propose a feature, improve the documentation, or contribute code, we’d love to have you involved.

Multipass is evolving beyond a virtual machine manager into a powerful local cloud sandbox for experimentation, learning, and development. We look forward to seeing what you’ll build with it.

[markcunninghamubuntu]

@cniederberger

Building on the custom image support introduced in the previous release, Multipass 1.17 adds direct support for additional Linux distributions, including Debian and Fedora. Yes, we open the door to let our users enjoy selected distributions other than Ubuntu and benefit from the respective variants as new playgrounds.

Hey @cniederberger

Great to have an update and what’s on the roadmap! And fantastic news to have official supported on Debian and Fedora.

I have a few comments that I wanted to add if that’s ok but happy to add a github issue instead.

First request: Standardize the image name

Currently the image names follow 1 standard for ubuntu and another for other distros. Example

$ multipass find
Image                       Aliases           Version          Description
22.04                       jammy             20260826         Ubuntu 22.04 LTS
24.04                       noble             20260826         Ubuntu 24.04 LTS
26.04                       resolute,lts,ubuntu20260823         Ubuntu 26.04 LTS
daily:26.10                 stonking,devel    20260810         Ubuntu 26.10
core:core16                                   current          Ubuntu Core 16
core:core18                                   current          Ubuntu Core 18
core:core20                                   current          Ubuntu Core 20
core:core22                                   current          Ubuntu Core 22
core:core24                                   current          Ubuntu Core 24
core:core26                                   current          Ubuntu Core 26
debian                      trixie            20260826         Debian Trixie
fedora                                        20260422         Fedora 44

for my multipass version if needed

$ multipass --version
multipass   1.17.0-dev.3952+g828bfa38
multipassd  1.17.0-dev.3952+g828bfa38

I feel like this is an important step for the roadmap to make multipass not just an ubuntu tool but an os agnostic tool. Right now you list the image names for ubuntu as their version numbers but for other distros, you give just a name. If people are using scripts, that breaks the understanding of the standard of what’s supposed to be in what key/column. Whatever way you standardize, there should be one column/key that says just ubuntu,debian,fedora and others like openbsd? etc etc, another for version that can have 26.04 or 26.04.1 etc and if you’re self hosting theses images from other OSes (like fedora) instead of linking to their release page to pull the cloud init images, then i think that’s where your version column comes into place.

I think this standardization as you expand to other OSes should be done as soon as you can before more people start using multipass and make assumptions written into scripts that are forgotten about what each column/key means and what should be there. Alternatively, do what APIs do and set a v2/v3 version of os/version selection with the api/cli that follows the new standard.

Second request/question - support/thoughts about OSes beyond fedora/debian
If i could ask more details about thoughts about further oses. What would be the plan of what to support in the future and how would you do this?

1: Would the idea be that you follow and implement cloud init on custom image links and if the cloud init image is built well, then any os hosting a cloud init image should work?
2: Would you aim to support any other oses officially in the store like you did with debian/fedora?
3: Will you aim to host these images (either fedora/debian or other oses if you go that way) or link upstream to the os release links (for example https://download.freebsd.org/releases/VM-IMAGES/14.3-RELEASE/amd64/Latest/)

I was building a project to test the impact of something across as many linux/unix based oses that were the top most used. I choose multipass. I hit some snags unfortunately as I realised the project wasn’t quite as mature as I thought. I tried to spin up some cloud init qcow images and had the vm stall. Unfortunately without serial/console access (which I may decide to give a shot at implementing here Support access to console log · Issue #136 · canonical/multipass · GitHub) , i couldn’t get any more debug information and just had to drop the idea of using multipass for this for now if I want to deliver my project without going down a rabbit hole of looking into multipass (which I can still do for the future but it seems the maturity isn’t there)

[cniederberger]

Hi @markcunninghamubuntu

Thanks for sharing your thoughts on opening Multipass towards other distributions.

This has been a long standing request from the community and we hope that this step can help us to get a broader user base and community acceptance. However, it is not in our plans to make Multipass an OS agnostic tool and, as you probably can understand, Ubuntu is the primary OS we support and will keep supporting.

Adding Debian and Fedora to the catalog is a first step. We are totally aware that this is not a full blown solution resolving every user need. Actually, I am pretty sure that there is quite some room for improvement.

Our approach is to take it step by step: If the addition of Debian and Fedora turns out to be successful and (hopefully) widely accepted, we will consider investing more and work towards support of (selected) distributions the same way as we currently support Ubuntu. While adding them is the initial effort, maintaining them is a completely different topic given the various distribution/release approaches in that area. We will take both aspects into account when making our decisions.

As of today, we will not commit to officially support or host any OSes other than the ones in the release. At the same time, I think that the addition of Debian and Fedora to the supported distributions in our catalog can be understood that we are opening up and exploring that as a potential strategic direction.

Having said this, we are open to hear feedback - like yours and from anywhere in the community - because that will help us in making these decisions.

[ricab]

Hi,

I just wanted to add a couple of points.

If people are using scripts, that breaks the understanding of the standard of what’s supposed to be in what key/column.

The recommended approach for scripting is to use one of 3 machine-friendly --formats that multipass provides: csv, json, yaml. For example: multipass find --format yaml says:

[...]
images:
  22.04:
    aliases:
      - jammy
    os: Ubuntu
    release: 22.04 LTS
    version: 20260826
    remote: release
  [...]
  debian:
    aliases:
      - trixie
    os: Debian
    release: Trixie
    version: 20260826
    remote: ""
  fedora:
    aliases:
      []
    os: Fedora
    release: 44
    version: 20260422
    remote: ""

Note that there are dedicated os and release fields to identify the distro and version.

Also, the IDs are subject to slightly different constraints depending on the distribution. We want all IDs to be intuitive as to which offered images they designate. But we have multiple Ubuntu images, which their IDs must distinguish, whereas debian and fedora already uniquely identify the single image for each of those distributions. Hope that makes sense.

[markcunninghamubuntu]

Hi @cniederberger

Thank you for the response on this. That makes complete sense and very understandable point of view, especially with not rushing to commit to supporting extra oses at this stage in the project. I think this is the kind of information that would greatly benefit from being added to the readme/roadmap as it makes it quite clear what the project is currently, and what it intends to be and what it could some day be.

And for example, I could have added a fix for an os that isn’t one of the ones mentioned (if it was a bug in multipass), but unless you’re at the stage where you’re willing to support that os going forward, it would be disservice to the users as they’d suddenly have support and then could potentially lose it later or it breaks (or it ends up overloading your team with operational work that pulls you away from your primary goals for features for the project).

Thank you for the time to respond on this

[cniederberger]

@markcunninghamubuntu - Thanks.

We decided to keep the repository readme and contribution document on the generic side but added a link to the Multipass Discourse topic where we share our vision and thoughts on our roadmap plans.

Our discussion here shows that this is probably the right place to ask questions and get answers for clarification.