Multipass 1.17 for Homelab: Fast Debian and Alpine VMs

Multipass 1.17 removes the Ubuntu-only restriction for local virtual machines. Canonical’s lightweight CLI orchestrator now directly provisions Debian and Fedora instances. For homelabbers testing pipelines or experimenting with container stacks, Multipass replaces the heavy overhead of spinning up full Proxmox VMs or maintaining Vagrant toolchains. The software wraps native hypervisors (KVM on Linux, the Apple Virtualization Framework on macOS, and the Host Compute System API on Windows) to launch disposable Linux environments in seconds.

Non-Ubuntu Distros in Your Homelab

The 1.17 release redesigns the Multipass image catalog to support third-party Linux distributions. Before this update, validating a service against a Debian environment meant provisioning a second virtualization stack or manually converting disk images. The tool now integrates a broader operating system catalog natively.

Listing available images using the CLI confirms the newly supported distributions.

multipass find

The output includes familiar Ubuntu LTS releases alongside debian and fedora images. Launching a Debian test node requires a single command specifying the distribution and the desired hardware resources.

multipass launch debian --name dev-debian --cpus 2 --memory 4G --disk 10G

Multipass provisions the virtual disk, configures the network bridge, and injects the SSH keys. Once the CLI returns control, the Debian VM is active. Connecting to the shell is immediate.

multipass shell dev-debian

Booting Alpine Linux from a Custom URL

While Debian and Fedora are built into the default catalog, Multipass 1.17 also supports launching instances directly from custom image URLs. The CLI accepts .img or .qcow2 files over HTTPS, making minimal distributions like Alpine Linux highly accessible.

Alpine provides official QEMU qcow2 cloud images equipped with cloud-init. The Multipass daemon downloads the image, configures the hypervisor backend, and boots the VM.

multipass launch https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/cloud/nocloud_alpine-3.20.3-x86_64-bios-cloudinit-r0.qcow2 \
  --name alpine-node \
  --cpus 1 \
  --memory 512M \
  --disk 1G

Multipass defaults to allocating 1 CPU core, 1GB of RAM, and a 5GB disk. While these settings suit Ubuntu, Alpine Linux requires far less overhead. A user can provision a functional Alpine VM with just 512MB of RAM and 1GB of disk space. Confirm the resource consumption by querying the instance status.

multipass info alpine-node

The output displays the VM state, assigned IPv4 address, system architecture, and exact memory utilization.

Cloud-Init for Cross-Distro Provisioning

Multipass relies heavily on cloud-init to customize virtual machines during the first boot. Launching non-Ubuntu images introduces a common access issue: the default user is no longer ubuntu. Debian images default to the debian user, and Alpine images default to alpine. Furthermore, Multipass file transfer commands assume the /home/ubuntu path exists.

Passing a custom cloud-config.yaml file normalizes access and configuration across all distributions. The following configuration creates a standard user, grants passwordless sudo access, and imports an SSH key from GitHub.

# cloud-config.yaml
users:
  - default
  - name: sysadmin
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_import_id:
      - gh:yourgithubusername

Apply the configuration during VM creation using the --cloud-init flag.

multipass launch debian --name provisioned-debian --cloud-init cloud-config.yaml

Once the VM boots, access the instance using standard SSH instead of the Multipass shell wrapper, or use multipass exec provisioned-debian -- <command> to run scripts remotely.

Running Docker Inside a Multipass VM

Homelab environments often require disposable Docker hosts. Multipass VMs provide strong isolation for testing untrusted containers without risking the host system or the primary Proxmox hypervisor. Deploying Docker via cloud-init automates the entire installation process. Save the following configuration as docker-init.yaml.

# docker-init.yaml
package_update: true
packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg
  - lsb-release
runcmd:
  - curl -fsSL https://get.docker.com | sh
  - systemctl enable docker
  - systemctl start docker
  - usermod -aG docker debian

Launch a dedicated Debian Docker host with two CPU cores and 4GB of RAM.

multipass launch debian --name docker-host --cpus 2 --memory 4G --cloud-init docker-init.yaml

Wait a few moments for the package installation to finish. The VM operates as a fully functional, disposable Docker environment.

multipass exec docker-host -- docker run hello-world

Multipass Gotchas for Non-Ubuntu Distributions

When running operating systems other than Ubuntu, certain default CLI behaviors fail because the underlying system assumptions change.

Mounting Host Directories

The multipass mount command links a local host directory directly into the virtual machine’s filesystem. This maps a source code folder into the VM so the host editor can modify files while the guest executes them.

multipass mount /local/path/to/project bridged-node:/mnt/project

If the target path is omitted, the CLI automatically attempts to mount the directory into /home/ubuntu/<folder>. This command fails silently or throws path errors on Debian or Alpine VMs because the directory structure differs. Always specify an explicit target path like /mnt/project when working outside the Canonical ecosystem.

File Transfers

The same path limitation applies to the multipass transfer command. Moving an archive into a non-Ubuntu VM requires explicitly targeting a universal directory such as /tmp.

multipass transfer app-config.tar.gz dev-debian:/tmp/

Attempting to push files directly into the VM without a destination path defaults to /home/ubuntu/ and fails.

Network Isolation

Multipass networks default to NAT. Virtual machines share the host’s IP address outbound but are not directly reachable from the wider local area network. To expose a Multipass VM to the rest of the homelab, use the --network flag to bridge the connection.

List the host’s physical and virtual interfaces.

multipass networks

Pass the desired interface name to the launch command. The VM will request an IP address directly from the local DHCP server.

multipass launch fedora --name bridged-node --network en0

Teardown and Resource Management

The Multipass architecture treats virtual machines as temporary instances. When a test pipeline concludes or an Alpine container host is no longer required, destroy the VM to reclaim system resources.

Stop the instance gracefully.

multipass stop dev-debian

Delete the instance. This marks the VM for removal but retains the data temporarily.

multipass delete dev-debian

Purge all deleted instances to free the disk space completely.

multipass purge

The CLI leaves no orphaned virtual disks or stale network bridges behind. The tool abstracts the hypervisor cleanup, ensuring the host machine remains clean regardless of how many Debian or Alpine VMs are provisioned and destroyed daily.

What’s Next

• MicroVMs in Proxmox: True Homelab Isolation, Simply
• Proxmox VE Homelab Setup: Install and Configure (2026)
• Docker Compose Homelab Stack: 20 Services, One File
• Linux Homelab Security Hardening: Complete Checklist (2026)