Step by step, with screenshots: an Ubuntu VM from a cloud image in 30 seconds, and Ubuntu Desktop installed without a single question.

Native arm64, not an emulated PC

Ubuntu on an Apple silicon Mac is Ubuntu's own arm64 build running on the CPU's native instruction set, the same build that runs on AWS Graviton servers and Raspberry Pis. Nothing is emulated. Canonical treats arm64 as a first-class target: the 26.04 LTS release brought Livepatch to arm64 and ships a generic arm64 desktop ISO meant for exactly this kind of machine.

The catch comes with the same fact. arm64 is a different architecture, not a compatibility mode, so anything built only for x86-64 won't run without help: a binary-only tool, an old .deb with no arm64 build, a container image published only as amd64. More on that below.

The fastest way in: Ubuntu's cloud image

Since Velo Workspaces 1.2, the quickest route to a working Ubuntu is Canonical's official cloud image. Create a workspace, choose Cloud image, pick Ubuntu 26.04 LTS or 24.04 LTS, and enter a username and password. The app downloads the image from cloud-images.ubuntu.com, checks it against Canonical's published checksum, and hands your account, this Mac's SSH key and a hostname to cloud-init on a small seed disk. First boot sets everything up, and the workspace is usually ready to sign in to about a minute after the download finishes.

There's no installer to click through, and the disk grows on first boot to whatever size you picked. With Pro, Open Terminal in the workspace's Access tab signs you in straight away, using the key the app keeps for this Mac. The Access tab also shows a plain ssh command for Terminal or any other client; that uses your own SSH key, so paste your public key under SSH Public Keys when you create the workspace. The cloud image is Ubuntu Server, with no desktop, which is what most development and CI-style work wants anyway. Curious what cloud-init is doing behind the scenes, or using QEMU or UTM instead? Ubuntu cloud images on a Mac, by hand covers the seed disk, the disk resize and SSH host keys.

When you want the installer: Server or Desktop, hands-free

Choose Installer image instead if you want Ubuntu Desktop, or a system laid out by Ubuntu's own installer. Leave Automatic installation on and the app writes an autoinstall file for Subiquity with your account, your SSH key, and this Mac's language, keyboard and time zone. It also boots the installer with autoinstall on the kernel command line, so Subiquity doesn't stop to ask anything, not even before it erases the disk. Leave it alone, and the workspace restarts into the installed system when it's done.

Turn automatic installation off and you get Ubuntu's normal interactive installer in the workspace's display, the same screens you'd see on a PC. Either way, the ISO comes from Ubuntu's own servers, is verified against its checksum, and stays in Settings › Images, so the next workspace doesn't download it again.

A networking gotcha when you clone Ubuntu Server

A workspace cloned from a saved Ubuntu Server (minimized) base image can come up without an IP address. Every workspace gets its own MAC address, clones included, and Ubuntu Server's minimized install writes a Netplan config that matches the network interface by the base image's original MAC instead of by name. The clone's MAC is different, nothing matches, and DHCP never runs. The fix is one line in /etc/netplan/, and the support FAQ has the commands. It looks like a mysterious clone-only bug until you know it's an interaction between Ubuntu's defaults and cloning.

Running x86-64 binaries: Rosetta, and its limits

When you need something that only ships for x86-64, Apple's Rosetta works inside a Linux guest too. With Pro, turn Rosetta on in the workspace's Resources tab; Velo Workspaces shares it into the guest over VirtioFS, and a one-time update-binfmts registration hands x86-64 binaries to it. Rosetta 2 in Linux VMs explains the mechanism, and the support FAQ has the commands (Ubuntu and Debian use the same ones). For how this fits alongside Rosetta for Mac apps, Homebrew's two prefixes and multi-arch containers, see ARM64 vs. x86-64 on Apple Silicon.

Know what it doesn't fix. Rosetta translates a dynamically linked x86-64 executable well, but it can't produce x86-64 packages that don't exist for arm64, and Ubuntu's arm64 ports mirror doesn't carry amd64 packages, so adding amd64 sources by hand often ends in a 404. A tool with x86-64-only libraries behind it, or one that needs a whole amd64 package tree, is much harder than translating one binary. Rosetta is the answer for the one tool you're stuck with, not a way to make the architecture stop mattering.

Putting it together

A pattern that works well: create Ubuntu Server from the cloud image, install what your base setup needs (packages, dotfiles, Rosetta if you use it), then save it as a base image. Every workspace after that is a clone of that known-good state, running in seconds. It's the same disposable-workspace pattern covered for QA and DevOps, and the setup behind the MLX and AI agent guide and the inference benchmarks on this blog, both on Ubuntu Server 26.04.

Related reading: Debian on Apple Silicon, whose networking defaults avoid the clone gotcha above; Fedora on Apple Silicon, which registers Rosetta a different way; Server or Desktop, if you're unsure which you need; and which distro fits your work, if you haven't decided. Or download Velo Workspaces and try it yourself.