Ubuntu Core 26 in a VM: A Local AI Appliance Checklist

Ubuntu Core 26 gives developers a practical way to test an appliance-style AI stack before they choose edge hardware. Canonical’s June 16 walkthrough shows Ubuntu Core 26 running in a Multipass virtual machine, then adds the gemma4 snap so the VM exposes a local inference server and WebUI. The useful lesson is not that every production device should be a VM. It is that the VM is a safe rehearsal space for the same operating model you will later need on a real appliance: a small immutable base, application snaps, managed services, explicit network exposure, and a repeatable acceptance test.

This checklist is written for Ubuntu Core 26, Canonical Multipass, and the gemma4 snap as described in Canonical’s source post. Treat the commands as a lab baseline, not a substitute for your hardware bill of materials, model license review, or production threat model.

Why Start With the VM Before Buying Edge Hardware?

Ubuntu Core is designed for embedded, IoT, robotics, industrial, and cloud-connected systems. Canonical’s documentation describes it as immutable and transaction-based, with image-based deployment, automatic updates, sandboxed applications, and rollback capabilities. That matters for local AI because an inference appliance is not just “Linux plus a model.” It is a product that must keep booting, updating, recovering, and exposing only the services you intend to expose.

A Multipass VM lets the team answer basic questions quickly: how much memory does the selected model need, which services start automatically, where does the API listen, what needs to be opened to the host, and what operational checks will be used before the image moves to hardware. If the lab cannot produce a clean runbook, the hardware version will not magically become easier.

The Lab Architecture

Ubuntu Core 26 as the appliance base

In this pattern, Ubuntu Core 26 is the device-oriented base operating system. The application workload is delivered as snaps rather than hand-edited packages spread across the filesystem. That separation is the point: the base system, snapd, and application services can be reasoned about independently when you later build a production image.

Multipass as the local test harness

Multipass provides the disposable local VM. Its launch command supports CPU, memory, disk, and name options, so the lab can start with explicit resource assumptions instead of hidden defaults. Canonical’s walkthrough uses a four-vCPU, 10 GB memory, 16 GB disk VM named aibox:

# Target: Ubuntu Core 26 running under Canonical Multipass on a developer workstation.
multipass launch core26 -n aibox --cpus 4 --memory 10GB --disk 16GB
multipass shell aibox

gemma4 as the inference workload

Inside the Ubuntu Core 26 VM, the AI workload is installed as a snap:

# Target: Ubuntu Core 26 VM named aibox, inside the VM shell.
sudo snap install gemma4
gemma4 status

The status output in Canonical’s example reports a CPU engine, active server services, an OpenAI-compatible endpoint, and a WebUI endpoint. Your acceptance test should use the exact endpoint reported by gemma4 status, because that is the contract your scripts and clients will depend on.

Expose the Service Deliberately

The common lab mistake is to see “localhost” in service output and assume the host browser can reach it. In this setup, localhost means the Ubuntu Core VM. Canonical’s runbook changes the snap options so the inference server and WebUI listen on the VM network interface:

# Target: gemma4 snap running inside the Ubuntu Core 26 VM.
sudo gemma4 set http.host=0.0.0.0 webui.http.host=0.0.0.0 --assume-yes

Then return to the host and read the VM address:

# Target: host workstation running Multipass.
multipass info aibox

Use the IPv4 address from multipass info for testing. If the VM reports 10.100.120.150, the WebUI in Canonical’s example is available at port 8337, while the API service is on port 8336. Keep the IP address as a variable in your notes so the runbook does not bake in one developer’s temporary address.

A Practical Acceptance Test

Before calling the lab “working,” verify the service from the same place your users or downstream applications will connect. A minimal test plan should cover service state, host reachability, and a single inference request.

# Target: host workstation. Replace the value with the IPv4 from `multipass info aibox`.
AIBOX_IP="10.100.120.150"

# Confirm that the WebUI port responds from the host network path.
curl -I "http://${AIBOX_IP}:8337"

# Confirm the API route using the route shown in Canonical’s raw cURL example.
curl "http://${AIBOX_IP}:8336/chat/completions" 
  -H "Content-Type: application/json" 
  -d '{
    "messages": [
      {"role": "user", "content": "Reply with one sentence about Ubuntu Core."}
    ],
    "max_completion_tokens": 80
  }'

If the raw request fails, do not guess. Go back to gemma4 status, confirm whether your client should use http://<ip>:8336/v1 as an OpenAI-compatible base URL or a different path, and record the exact command that worked on your version of the snap.

Production Checklist Before Moving Beyond the VM

1. Resource budget

The VM baseline is intentionally generous for a small local lab: four CPUs and 10 GB of memory. Record actual memory pressure, startup time, and response latency under the prompt sizes your application expects. If you plan to move to an edge board, repeat those measurements on the real CPU, GPU, NPU, storage, and thermal profile.

2. Snap configuration and service ownership

Snapcraft’s documentation groups day-to-day snap operations around installation, configuration, updates, services, and confinement. For an appliance, that means every production setting should be captured as a snap option, model assertion, image-build input, or deployment policy. Avoid “SSH in and edit a file” procedures unless they are explicitly part of a break-glass support path.

3. Network exposure

Binding to 0.0.0.0 is acceptable in a controlled VM lab so the host can test the service. It is not a complete production network policy. Before shipping, define which interface should listen, how the service is authenticated, whether the WebUI should exist in production, and which firewall or gateway rule protects the inference API.

4. Update and rollback behavior

Ubuntu Core’s value proposition includes automatic updates and rollback. Test that behavior before you depend on it. A production image should have a documented channel strategy, a way to hold or validate updates when needed, and a recovery procedure that operators can execute without becoming Linux forensic experts.

Minimum release gate

• The VM can be recreated from a short runbook without manual mystery steps.
• gemma4 status shows the expected engine, services, and endpoints.
• The host can reach the WebUI and API only through approved network paths.
• A scripted prompt returns a response and logs the endpoint path that was used.
• Resource measurements are captured before choosing real edge hardware.
• Image-build, update, rollback, and support procedures are documented.

What Not to Infer From the Demo

This lab does not prove that one model is safe for your use case, that CPU inference is fast enough for every workload, or that exposing a local API is secure by default. It proves something narrower and still valuable: Ubuntu Core 26, Multipass, and a snap-delivered inference workload can be assembled into a repeatable local appliance pattern. The production decision comes after measurement, threat modeling, model governance, and hardware validation.

Source Notes

This checklist is based on Canonical’s Ubuntu Blog post, “A look into Ubuntu Core 26: Building a local AI inference appliance in a virtual machine”. Supporting references include the Ubuntu Core documentation, Canonical’s Multipass launch reference, the Snap documentation, and the featured image’s Wikimedia Commons license page.