Snap

Snap types & Ubuntu Core

Not every snap is the same kind of thing. A handful of special-purpose snap types are what make Ubuntu Core possible at all — a Linux distribution built entirely out of snaps, with no apt, where even the kernel and bootloader configuration update and roll back exactly like an application does.

The five formal snap types

The type: field in snapcraft.yaml accepts exactly five values. If you omit it, you get app.

"System snap" vs. "application snap"

These two terms aren't values of type: — they're everyday shorthand for grouping the five formal types by role:

In other words: on an Ubuntu Core device, the four system snaps are the OS image, and everything else on the device is an application snap running on top of them.

Gadget snap, in depth

The gadget snap is the one piece of an Ubuntu Core image that's genuinely specific to a board. It carries its own manifest, meta/gadget.yaml, describing:

• volumes — the on-disk partition layout: bootloader region, a system-boot partition (boot assets), a system-data partition (writable state), sizes and offsets.
• bootloader stanza — which bootloader the board uses (u-boot, grub, piboot, ...) and its config, tying straight back to U-Boot.
• structure roles — marks which partition is system-boot, which is system-data, etc., so snapd knows where to write updates.
• device tree — board-specific .dtb/overlays, the same device tree concept covered in Linux → Boot.

Building a new board target usually means writing a new gadget snap, not touching the kernel or base snaps at all — the split is deliberate, so board-specific bring-up work stays isolated from the rest of the OS.

Kernel snap, in depth

Packages the kernel image, loadable modules, and initrd that the bootloader (configured by the gadget snap) actually boots. On secure devices it's signed, and forms one link in the same chain of trust described in Bootloader fundamentals — the gadget's bootloader stanza verifies the kernel snap's signature before jumping to it. Updating the kernel snap is an atomic, rollback-capable operation exactly like updating an application snap.

Base and snapd snaps

The base snap (e.g. core22) supplies the minimal userspace — C library and friends — that runs on top of the kernel and underneath every application snap; on an Ubuntu Core device it effectively is the root filesystem. The snapd snap ships the snap daemon itself, so the component responsible for updating everything else can also be updated and rolled back the same way.

How they combine to boot Ubuntu Core

Two properties fall out of this directly: atomic, transactional updates (each snap is a whole immutable image — an update either fully applies or fully doesn't) and automatic rollback (if a freshly-updated kernel or base snap fails a health check on boot, the bootloader falls back to the previous working revision without operator intervention — critical for devices nobody can walk up to and re-flash).

Inference snaps

"Inference snap" isn't a formal type: — it's a common real-world pattern for how edge-AI workloads get packaged: an ordinary type: app snap purpose-built to run a machine learning inference engine (and often a model) on the device, as opposed to an app snap that's, say, a web server or a CLI tool. They show up constantly on NPU-equipped boards (e.g. an i.MX8MP) running Ubuntu Core.

What tends to make an inference snap look different from a typical app snap:

• Runtime and model split across two snaps, connected by the content interface (see Packaging → Plugs and slots) — the inference engine binary ships in one snap, the trained model ships in another, and they're updated independently. A model retrain doesn't require rebuilding or re-certifying the engine, and vice versa.
• Hardware-specific interfaces — access to a GPU or NPU device node, camera, or other accelerator, each requiring its own interface connection under strict confinement rather than broad system access.
• Fleet-safe update story — the same atomic update/rollback model described above is exactly what makes it reasonable to push a new inference engine build to a fleet of remote, physically inaccessible devices: a bad update rolls itself back instead of bricking hardware nobody can drive to.

Real-world applications

• Industrial gateways and PLCs — Ubuntu Core's atomic updates and rollback are a strong fit for devices deployed in factories, where a bad update failing safely matters enormously.
• Edge-AI camera/vision systems — the inference-snap pattern (engine and model split via the content interface) is exactly how many NPU-equipped edge devices structure their ML pipeline.
• Digital signage and retail kiosks — a locked-down, remotely-updatable OS with strict confinement suits unattended public-facing hardware.
• Telecom/network appliances — Ubuntu Core devices are used as small-footprint routers and network functions where every layer needs to be independently, safely updatable.

Gotchas