snap vs apt: When to Use Which on Ubuntu Server

If you’ve spent any time around Ubuntu, you’ve probably noticed it has two package systems: apt and snap. This causes genuine confusion, and there’s a fair amount of strong opinion about it online. Here’s a straight, practical explanation of what snap actually is and when it makes sense on a server.

What snap actually is

snap is Canonical’s own packaging format. A snap bundles an application together with its dependencies into a single, self-contained, sandboxed package, rather than relying on shared libraries already installed on the system, which is how traditional apt/.deb packages work. Snaps are managed by a background service called snapd, which is installed by default on Ubuntu Server.

Two properties define snap in practice:

• Auto-updating. Snaps check for and install updates automatically in the background, on a schedule you can adjust but not fully disable long-term without a policy.
• Sandboxed. Snaps run with confined permissions and access system resources (network, files, devices) through defined interfaces, similar in spirit to mobile app permissions.

What’s actually snap-based on Ubuntu Server

A default Ubuntu Server install is overwhelmingly apt-based – the base system, standard services, and most packages you’d install for a typical VPS workload come from apt. snapd itself is present by default, and a small number of core system components (such as the core base snaps that snapd relies on) are snaps under the hood. Some specific tools have shifted to being distributed primarily or exclusively as snaps over time – LXD (Canonical’s container/VM manager) is a notable example, and the EFF recommends Certbot via snap for the most up-to-date builds. Outside of cases like these, you generally choose apt or snap yourself depending on what’s available and what you prefer for a given piece of software.

The genuine trade-offs

snap

• Pro: automatic updates mean you’re less likely to run outdated, vulnerable versions of an application without noticing.
• Pro: sandboxing limits what a compromised application can touch on the rest of the system.
• Con: because dependencies are bundled rather than shared, snaps generally use more disk space than the equivalent apt package.
• Con: some snaps have noticeably slower cold-start times than their apt equivalents, since they’re launched inside a sandboxed mount namespace.
• Con: updates happen on Canonical’s schedule by default, which on a production server can mean a service restarts or changes version at a time you didn’t choose.

apt

• Pro: lighter weight, faster startup, shared system libraries.
• Pro: updates only happen when you run them (or when you’ve explicitly configured unattended-upgrades), so you control the timing.
• Con: no built-in sandboxing – packages run with the same access as any other process on the system.
• Con: package versions in the stable repositories can lag behind upstream, particularly on an LTS release.

Practical guidance for a VPS

For most server workloads – web servers, databases, application runtimes – prefer the apt package where one exists and is reasonably current. It’s lighter, starts faster, and updates on your schedule, which matters more on a server than on a desktop.

To see what snaps are installed on your system and check for pending updates:

snap list
snap refresh --list

If a snap auto-updates at a time that’s disruptive, you can hold it at its current revision:

sudo snap refresh --hold=forever 

Or hold it for a set period instead of indefinitely:

sudo snap refresh --hold=24h 

You can also set a preferred maintenance window for automatic snap refreshes system-wide, so they happen at a time you choose rather than whenever Canonical’s servers decide:

sudo snap set system refresh.timer=mon,03:00-05:00

Neither system is wrong – they solve different problems. The practical rule for an unmanaged VPS: default to apt for predictability, use snap deliberately when a package genuinely is snap-first (or snap-only), and if you do rely on a snap for something production-facing, take control of its refresh schedule rather than leaving it on Canonical’s default timing.