A Snap is a self-contained application package for Linux that bundles a program together with the libraries it needs, is installed and managed by the snapd daemon, and runs under strict confinement by default. In Linux package management, a Snap is one of the main universal packaging formats, designed so that a single build runs on many Linux distributions instead of being rebuilt for each one.
Snaps are distributed mainly through a central store, receive automatic background updates, and can describe desktop applications, command-line tools, background services, and even the core of an operating system. The format competes and overlaps with Flatpak and AppImage, but it differs from both in its packaging model, its update mechanism and its reach beyond the desktop.
How a Snap package works
A Snap works by shipping the application as a compressed, read-only SquashFS image that snapd mounts at a fixed location instead of unpacking files into the system directories. The mounted image appears under /snap/<name>/<revision>, while writable data is kept separately in per-revision and shared data directories.
The package contents are defined in a snapcraft.yaml file and built with the Snapcraft tool. Each Snap depends on a base snap, such as core22 or core24, which provides a minimal runtime derived from a long-term-support release. Because the base is shared, the application does not depend on the libraries of the host distribution, which is the main source of its portability.
At run time, snapd applies AppArmor profiles, seccomp filters and mount namespaces to restrict what the application can see and do. Access to resources outside the sandbox is granted through interfaces, which pair a plug on the consuming Snap with a slot on the system or another Snap. The table below lists the main components involved.
| Component | Role | Where it lives |
|---|---|---|
| snapd | Daemon that installs, mounts, updates and confines Snaps | Host system service |
| snap command | Command-line client for users and administrators | Host system |
| SquashFS image | Compressed, read-only package payload | /var/lib/snapd/snaps |
| Base snap | Minimal runtime the application builds against | Separate shared Snap |
| Interfaces | Controlled permissions such as network, home or camera | Declared in snapcraft.yaml |
| Store | Distribution, signing and channel management | Remote service |
Confinement levels, channels and revisions
Every Snap declares a confinement level that determines how strongly it is isolated from the host. Most published applications use strict confinement, while development tools that must reach arbitrary files often use classic confinement, which requires manual review before it is accepted for public distribution.
| Confinement level | Isolation | Typical use |
|---|---|---|
| Strict | Full sandbox, access only through connected interfaces | Desktop apps, servers, utilities |
| Classic | No sandbox, behaves like a traditional package | Compilers, editors, IDEs |
| Devmode | Violations are logged but not blocked | Development and testing only |
Updates are organized into channels, written as track/risk/branch. The risk levels stable, candidate, beta and edge let a publisher promote the same revision from testing to production. Each upload receives an increasing revision number, and snapd keeps the previous revisions locally, by default two or three revisions, so that snap revert can return to a known working build within seconds.
snapd checks for updates about four times a day by default. Administrators can shape this with the refresh.timer setting, defer updates with snap refresh --hold, or pin a specific channel. Delta updates download only the changed parts of the image, which reduces transfer size for large applications.
Snap compared with Flatpak, AppImage and native packages
Snap differs from its neighbors mainly in scope, runtime model and governance. Flatpak targets desktop applications and shares runtimes such as GNOME or KDE platforms, AppImage is a single portable file with no installation step, and native formats such as DEB or RPM integrate tightly with the distribution but must be rebuilt for each release.
| Format | Sandbox | Updates | Scope |
|---|---|---|---|
| Snap | Strict by default | Automatic through snapd | Desktop, CLI, services, IoT |
| Flatpak | Bubblewrap portals | Manual or scheduled | Mainly desktop apps |
| AppImage | None by default | Optional self-update | Portable desktop apps |
| DEB or RPM | None | Through the distribution | Whole system |
A notable difference is that the reference Snap Store is a single proprietary service, while Flatpak repositories can be hosted by anyone. Snap can also package system services, kernels and gadget definitions, which makes it the basis of an entire immutable operating system for embedded devices rather than only a way to deliver applications.
When to choose a Snap
A Snap is the right choice when a publisher needs one build for many distributions and reliable automatic updates across a fleet. It is less suitable when a program needs deep integration with the host, very fast cold start, or full independence from a central store.
| Situation | Recommended choice | Reason |
|---|---|---|
| Server tool on many distributions | Snap | Single build with managed updates |
| Fleet of embedded devices | Snap on an immutable system | Transactional updates and rollback |
| Desktop app for many distributions | Snap or Flatpak | Both offer sandboxed portability |
| Core system library | Native package | Must integrate with the distribution |
| Single portable tool on a USB drive | AppImage | No daemon or installation needed |
Limitations and common problems
Snaps carry several practical trade-offs that experienced administrators plan for. Most complaints come from the cost of isolation and from the automatic update model rather than from defects in individual packages.
- Slower first launch: mounting the image and decompressing data can delay a cold start, although recent compression choices have reduced the gap.
- Disk usage: bundled libraries and retained revisions consume more space than a shared native package.
- Theme and font integration: strictly confined desktop apps may not match the host look unless the matching theme Snaps are installed.
- Unexpected updates: background refreshes can restart services, so production systems should set a refresh window or hold updates.
- File access surprises: the home interface does not cover hidden files or paths outside the home directory, which often explains missing-file errors.
- Many loop devices: each mounted revision appears as a loop device, which clutters disk listings but is not a fault.
In plain words
A Snap is like a sealed lunchbox for a program. Everything the program needs is packed inside, so it works the same on almost any Linux computer, no matter what else is installed there.
The lunchbox stays closed unless the system gives it permission to touch things such as your files, camera or network. A background helper keeps every lunchbox up to date and can swap back to the previous version if a new one causes trouble. The cost is that the boxes take a little more space and can open a little more slowly.
A real-world example
A small operations team runs a monitoring agent on 240 Linux servers that use three different distributions. Building and testing separate DEB and RPM packages for every release took several days, and older servers often lagged behind by months.
The team packages the agent as a strictly confined Snap with the network and system-observe interfaces, publishes test builds to the beta channel on ten servers, and promotes the same revision to stable after a week. They set the refresh timer to a nightly maintenance window so that services never restart during business hours.
When a later release mishandles a configuration file, the team runs a single revert command across the fleet and every server is back on the previous revision within minutes. The result is one build, one release process and a fast rollback path instead of three separate packaging pipelines.