Snap Packages: A Containerized, Self-Updating Format
The .deb model covered in apt and Repositories and dpkg and Dependencies relies on one assumption: a package depends on shared libraries already present on the system (libssl, libc6), so it only runs correctly where matching library versions exist. This is normally an advantage — it saves disk space, since many programs share one common library. But it occasionally becomes a constraint: if a piece of software depends on a much newer library version than the distribution's official repository currently provides, installing it through apt becomes difficult or impossible.
Ubuntu's developer, Canonical, addressed this with a different approach: Snap — a format that bundles an application together with nearly all of its dependencies into one self-contained package, largely independent of the distribution's own libraries. This article covers how Snap works, how it differs from apt in practice, and when it is the right choice for a production server — and when it is not.
What a Snap Actually Is
A Snap is a package format built as a read-only, compressed filesystem (squashfs) bundling an application together with its required libraries and metadata. Unlike a .deb file, a snap barely relies on the system's shared libraries at all — it carries almost everything it needs internally. This sidesteps the dependency problem covered earlier in a different way: a snap does not need to search the system for a dependency, because that dependency is already bundled inside the package.
This tradeoff has two sides:
- advantage — a snap is nearly independent of which distribution version is running underneath, adopts new upstream versions faster, and installs identically every time regardless of the host system's exact state;
- cost — package size is significantly larger (since libraries are duplicated rather than shared), it uses more disk space, and first launch is typically slower than the equivalent
.debpackage, because the application runs inside an isolation layer.
Running and managing snaps requires a background service, snapd. Modern Ubuntu Server LTS releases usually ship with snapd preinstalled.
snap Commands
Searching and Installing
snap find searches the Snap Store's available packages — the Snap-world equivalent of apt search.
In this example, core22 is a base runtime snap built on Ubuntu 22.04; many application snaps depend on a "core" snap like this one. sudo is required because snapd operates at the system level.
Viewing Installed Snaps
Name Version Rev Tracking Publisher Notes
core22 20240111 1122 latest/stable canonical✓ base
lxd 5.21.2 28372 5.21/stable canonical✓ -
Rev is this snap's exact revision (version) number; Tracking shows which channel it is following (covered below).
Updating
The first command updates every installed snap; the second updates only one. Unlike apt upgrade, snaps normally also update automatically, on a schedule not directly controlled by the administrator by default — a detail requiring specific attention on a production server, covered further below and in Production Updates.
Reverting to a Previous Version
A key advantage of Snap is that it retains the previous version after every update, so if a new version causes a problem, revert provides an immediate way back to a previously working state — a snap-level instance of the broader rollback strategy covered in Production Updates.
Removing
By default, snap remove does not delete a snap's data entirely — it keeps the last two revisions temporarily, in case you reinstall it later. For a complete, no-trace removal:
Confinement: How a Snap Is Isolated
Snap applications run in a containerized, restricted-privilege environment, unlike an ordinary .deb-installed program. This isolation level is called confinement:
| Level | Meaning |
|---|---|
strict |
Full isolation: the application can only access resources (files, network, devices) it has been explicitly granted through an interface |
classic |
Isolation is essentially disabled; the application has full system access like an ordinary program (for example snap install lxd --classic) |
devmode |
Developer- and testing-only mode with relaxed security restrictions |
The confinement: line in this output shows exactly which level applies. Which system resources a strict-mode snap can access is defined through interfaces (for example network, home, removable-media); to view and manage them:
Note
A snap installed with classic confinement has almost no isolation — this is often necessary, since some applications (an IDE, a system tool) genuinely require full filesystem access. But it also means a classic snap carries essentially the same security exposure as an ordinary .deb package — only install one from a source you actually trust.
Channels: Multiple Update Tracks for One Package
Every package in the Snap Store is distributed across several channels — a way to offer different stability tiers of the same software simultaneously, unlike apt's single static version:
| Channel | Stability level |
|---|---|
stable |
The default, production-ready version |
candidate |
The last verification stage before promotion to stable |
beta |
New features, not yet fully tested |
edge |
The most recent nightly build — can be unstable |
A production server almost always uses the default stable channel; any other channel is a deliberate choice reserved for a testing environment.
Snap vs. apt: When to Choose Which
| Criterion | apt (.deb) |
Snap |
|---|---|---|
| Dependency source | Shared libraries on the system | Bundled inside the package, nearly self-contained |
| Disk usage | Smaller (libraries shared) | Larger (libraries duplicated) |
| Update control | Fully manual or via unattended-upgrades |
Automatic by default; administrator can restrict the schedule |
| Version freshness | Depends on the distribution repository's pace | Often updates faster |
| Isolation | None — runs directly on the system | Partially isolated in strict mode |
Practical rule: if the software is available in the official Ubuntu repository and its update cadence is acceptable, prefer apt — it is lighter and gives you full control over the update schedule. Snap fits situations where the software is unavailable or too outdated in the repository, or where the isolation itself is a genuine benefit.
Interview angle
"Why would a team choose Snap over apt for one specific tool, and what does that decision cost them operationally?" is a fair interview question, and the honest answer names both sides: faster access to upstream releases and consistent behavior across hosts, traded against larger disk usage, slower first launch, and — critically — an automatic update mechanism that must be deliberately scheduled on a production server, or it will restart a service at an unpredictable time.
The Production Concern: Automatic Updates
Snap's default behavior is to update installed packages automatically, in the background, typically checked several times a day, without requiring an administrator's command. This is convenient on a workstation, but on a production server it can trigger an unexpected service restart or version change at an inconvenient moment.
Check the next scheduled update time:
While it cannot be disabled entirely, the update window can be restricted:
This restricts automatic refreshes to only Saturdays, between 23:00 and 04:00 — a snap-level, practical instance of the "maintenance window" idea covered in more depth in Production Updates.
Warning
If you run Snap on a production server, deliberately configure the automatic update schedule. Left at the default, a service can restart briefly at an inconvenient time — for example, during a daytime traffic peak.
A Practical Scenario: Auditing and Restricting snapd on a Server
Problem. On a freshly installed, minimal Ubuntu Server LTS machine, you notice snapd consuming resources (a background service, automatic updates) and want to understand why it is present and how to control it.
Step 1. Confirm snapd is running and see what is installed.
Step 2. Estimate disk space in use.
This is a read-only check that changes nothing.
Step 3. If snap is not actually needed (for example, a minimal server that runs no snap-packaged application), evaluate restricting the update schedule or removing snapd entirely.
If the list contains only system-required core/bare snaps and nothing else in actual use, removing snapd may be worth considering:
Danger
Before removing snapd, confirm nothing important actually depends on it — some modern Ubuntu tools (for example lxd) are distributed only as a snap. Review snap list output carefully before apt purge snapd, and if a genuinely needed snap exists, replace it with an alternative (a .deb version, if one exists) first.
Verify:
An empty result (or "command not found") confirms snapd and its related commands are removed from the system.
Conclusion. Snap is useful when actually needed, but not mandatory on every server. On a minimal, narrowly scoped server, removing it entirely is a common practice for saving resources and keeping a fully controlled update policy.
Common Mistakes
Installing Both a Snap and an apt Package for the Same Application
Some software (for example nginx) is available through both apt and the Snap Store. Installing both simultaneously leads to port conflicts or confusion about which version is actually running. Check with dpkg -l and snap list first to see which one is already installed.
Trusting classic Confinement Like an Ordinary strict Snap
A snap installed with --classic has essentially no isolation. Installing one from an untrusted source carries roughly the same risk as installing an unverified, unvetted .deb file.
Not Configuring the Automatic Update Schedule on a Production Server
A snap left at default settings can update itself at any time, including a peak traffic period. Setting a window with snap set system refresh.timer=... is a simple, effective way to prevent unexpected interruptions.
Treating snapd's Resource Usage as "Just a Background Service"
snapd runs as a persistent background process consuming CPU and memory even when no snap application is actively in use. On resource-constrained small servers, removing it when genuinely unneeded can make a measurable difference.
Exercises
- Compare the output of
snap listanddpkg -l | wc -lto determine how many snaps and how many.debpackages are installed on your system. - Find the
confinementline in the output ofsnap info core22(or any other snap available on your system) and explain why it is set to that specific level. - Use
snap refresh --timeto find the next scheduled automatic update time. If this server were in production, assess whether that time could fall within business hours, and if so, plan (without actually running it) which update window you would set instead.
Verification criterion: for each exercise, you should be able to clearly explain how Snap differs from apt in the specific dimension being examined — isolation, update behavior, or disk usage — and make a reasoned decision about whether to use Snap on a production server.
Summary
Snap bundles an application and its dependencies into one isolated package, largely independent of the distribution's own libraries — a different solution to the dependency problem inherent in the .deb model, at the cost of larger size and, by default, updates outside the administrator's direct control. apt and Snap are not competitors so much as two tools suited to different situations — the choice depends on where the software comes from, how much isolation is needed, and how tightly updates must be controlled.
Both formats — whether managed manually through apt or updated automatically through Snap — ultimately lead to the same underlying question: when and how should updates be applied safely on a production server? The next article, Production Updates, answers exactly that.
References
- Snapcraft documentation: Snap overview: https://snapcraft.io/docs
- Snapcraft documentation: types of confinement: https://snapcraft.io/docs/snap-confinement
- Snapcraft documentation: channels: https://snapcraft.io/docs/channels
- Snapcraft documentation: managing updates: https://snapcraft.io/docs/managing-updates
- Ubuntu manual page:
snap(1): https://manpages.ubuntu.com/manpages/noble/man1/snap.1.html