Snap

Fundamentals

Snap is Canonical's containerized packaging format: an application and all its dependencies bundled into a single compressed, read-only filesystem image, installed and updated independently of the host OS's own package versions.

Quick reference

What it is: A containerized package format: an app and its dependencies bundled into one read-only, independently-updatable image.
Mental model: A shipping container — everything the app needs travels together, sealed, so it runs the same regardless of what's on the host.
Key numbers: 3 confinement levels (strict/classic/devmode); channels follow a track/risk naming scheme.
Reach for it when: You want an application to update independently of the host OS, with automatic rollback if an update breaks.

What's actually inside a snap

A .snap file is a squashfs image. When installed, it's mounted read-only at /snap/<name>/<revision>, and the running application sees its own bundled libraries rather than whatever versions happen to be installed on the host — the same motivation as containers or Flatpak: eliminate "works on my machine" dependency drift.

Confinement

Level	Isolation
strict	Full sandbox (seccomp, AppArmor); access to the system is only through explicitly declared interfaces (network, home, camera, etc.).
classic	No sandboxing — behaves like a traditional package; used when an app genuinely needs unrestricted system access.
devmode	Confinement violations are logged, not blocked — a debugging aid during development, not for production.

Strict confinement is the default and the point of the format from a security standpoint: a compromised or buggy strictly-confined snap is limited to whatever interfaces it was explicitly connected to.

Channels and tracks

Every snap can publish multiple release streams simultaneously along a track/risk naming scheme, e.g. latest/stable, latest/edge, or a versioned track like 20/stable. This lets a device pin to a specific track for long-term stability while still receiving stability-risk updates within it — important on devices you don't want silently jumping major versions during an automatic update.

snap install mypackage --channel=20/stable
snap refresh mypackage --channel=20/edge   # switch tracks/risk

Automatic updates and rollback

Snaps update themselves automatically by default (checked periodically), and the previous revision is kept on disk — a failed update can be rolled back to the last known-good revision without needing external recovery tooling. On Ubuntu Core devices this extends to the OS, kernel, and bootloader snaps themselves, all versioned and rollback-capable the same way.

Real-world applications

Ubuntu Core edge/IoT devices — the entire OS ships as snaps, giving fleet-safe atomic updates — see Snap types & Ubuntu Core.
Digital signage and kiosks — strict confinement limits what a display application can access, useful for unattended public-facing devices.
Desktop application distribution — many Linux desktop apps (VS Code, Spotify) ship as snaps precisely to avoid dependency conflicts with the host distro's packages.
Remote/unattended devices — automatic rollback on a failed update matters most exactly where nobody can walk up and fix a bricked device by hand.

What I learned

A strictly confined snap failing with a permission error that "should work" is very often a missing interface connection, not a bug in the app — check snap connections <name> before debugging further up the stack.