snapd: the background daemon that installs and confines snap packages on Linux

snapd manages confined packages; the snap command is the user-facing half

The project splits into two halves. snapd is the background daemon that manages snap package installation, automatic updates and confinement enforcement. The snap command is the user-facing interface for interacting with the snap ecosystem, and both pieces come from this repository.

Snap packages target three contexts: desktop applications, cloud workloads and IoT devices. A single package format covers all three. That is an architectural commitment that affects how confinement is designed: the same isolation mechanism that makes sense for a desktop application must also hold on an embedded device with limited hardware. Automatic updates are a default behavior of the format, not something a user opts into.

Confinement is what separates this from a traditional package manager. snapd implements policies that isolate each snap from the base operating system and from other installed snaps. A governed interface layer controls exactly which system resources any given snap may reach. Without an explicit interface grant, a snap cannot call the kernel interfaces or read files outside its own directory scope.

Recent releases: 2.76.3 on 2026-08-20, 2.77 on 2026-09-03 and 2.77.1 on 2026-09-08. The last repository push was on 2026-10-06. The repository is not archived.

The interfaces layer decides which kernel resources a snap can access

Each interface in snapd represents a specific kind of system access: network connectivity, access to the desktop session, permission to reach USB hardware, and dozens of other slots. A snap that needs one of these must be connected to the corresponding interface. Without that connection, the relevant system calls are blocked by the confinement policy.

Snapd governs these connections from three sources. An automatic policy handles common, well-understood interfaces without user interaction. The snap's declaration in the store can override or restrict what is allowed. A user with sufficient privilege can also grant or revoke connections manually. The interfaces/ directory in the repository holds the full implementation of each policy type, and reading it is the most direct way to understand what a given interface name permits on the host system.

This differs from a model where a package simply lists claimed capabilities. In snapd's approach, both the store and the local daemon participate in deciding what a snap may do, and those decisions layer on top of each other. Full documentation of the interface types lives on the docs site at snapcraft.io/docs rather than in the README.

Finding snapd and installing the first snap

snapcraft.io/docs/installing-snapd is where the full installation guide lives. The exact steps depend on the Linux distribution: many Ubuntu releases ship with snapd already present, while other distributions require an additional package source. No install commands appear in the README itself.

Once snapd is running, published packages live in the Snap Store at snapcraft.io/store. Two examples the README cites are Spotify at snapcraft.io/spotify and Visual Studio Code at snapcraft.io/code. A publisher uploads a snap to the store, and the store handles version management and update delivery to all installed instances from that point on. Because the store controls update signing, packages do not update through any other channel by default.

For developers who want to build or modify snapd, HACKING.md at the repository root is the required starting point. It covers the manual build process and development setup in detail, while the README itself only points there. Anyone packaging a modified snapd for a downstream Linux distribution should read that file before anything else, since the repository does not expose build instructions anywhere else.

gorilla/mux routes the daemon REST API; bbolt holds local snap state

The go.mod file reveals the core architecture through its dependencies. gorilla/mux v1.8.0 is the HTTP router, which indicates that the snap command and the snapd daemon communicate through a REST interface over a local socket. Keeping those two pieces separate allows each to run at a different privilege level, and all state changes pass through the API layer.

bbolt v1.3.9 is an embedded key-value store. Persistent snap metadata, interface connection state and cryptographic assertion data all need a storage layer that works without a separate database service, and bbolt fills that role. An embedded approach also fits IoT hardware where adding PostgreSQL to the system image is not practical.

The module path is github.com/snapcore/snapd and the minimum Go version is 1.18, according to go.mod. Top-level repository directories cover daemon operation, client communication, interface enforcement, assertions, image creation, boot management and bootloader integration.

secboot and go-tpm2 v1.16.2 integrate snapd into measured boot and full-disk encryption

go.mod pulls in github.com/snapcore/secboot and github.com/canonical/go-tpm2 v1.16.2, which marks snapd as a participant in Canonical's full-disk encryption stack rather than a pure user-space package manager. secboot is the library behind disk encryption on Ubuntu Core IoT devices and Ubuntu desktops with FDE enabled. go-tpm2 provides Go bindings for TPM 2.0 hardware security modules.

github.com/canonical/go-efilib v1.8.0 rounds out the picture: snapd integrates with EFI boot environments. For an IoT image, that means snapd participates in measured boot: the bootloader, kernel and root filesystem are hashed and sealed into TPM registers, and a mismatch in those hashes prevents the drive from decrypting.

The README does not document this feature set at all, so the go.mod is the only indication from the repository itself. The go.mod shows secboot and go-tpm2 as compiled-in dependencies rather than optional modules, which means every snapd build carries that code regardless of whether the target hardware has a TPM. Whether a given Ubuntu or Ubuntu Core image actually uses full-disk encryption depends on how the image was constructed.

GPL-3.0 applies to all snapd builds; bugs go to Launchpad, not GitHub Issues

snapd is licensed under GPL-3.0, with the full licence text in the COPYING file at the repository root. GPL-3.0 covers any modified snapd build that is distributed. This includes distribution as part of a commercial appliance, an IoT image or a server deployment. This article does not offer legal advice on what that licence permits or restricts in any specific situation.

Bugs go to Launchpad at bugs.launchpad.net/snapd. The README is explicit: bugs belong on Launchpad, not on GitHub, and feature suggestions go to the Snapcraft forum at forum.snapcraft.io. Real-time discussion happens on the #snappy IRC channel on Libera Chat, and security issues have a separate process documented in SECURITY.md at the repository root.

The repository also holds ARCHITECTURE.md, CODING.md and CONTRIBUTING.md at the top level, alongside HACKING.md. For anyone packaging a modified snapd for a downstream distribution, these files document the structure and constraints the codebase imposes.

Snaps require Snap Store access; Flatpak takes a different approach to distribution

Snap packages in the standard flow depend on the Snap Store for installation and update delivery. The store signs each release and delivers assertions that the daemon verifies locally. In an air-gapped network, that dependency does not disappear: updates cannot arrive from the store, and assertions for new packages cannot be fetched. The README gives no documented offline installation path.

Flatpak is the other widely used confined-package format on Linux. Where snapd routes all packages through a single central store backed by a persistent daemon, Flatpak distributes through independently hosted repositories and uses D-Bus portals as the controlled path for system access rather than a vendor-managed interface layer. Both provide confinement on Linux desktops, but they differ on who controls the distribution channel and how interface permissions are negotiated at runtime.

For Ubuntu Core IoT deployments, the Store dependency is expected and designed for. For general-purpose enterprise Linux deployments where network access to external services is restricted by policy, the Store dependency is the constraint to resolve before adopting snap as the application delivery mechanism.

Editorial conclusion

snapd suits a deployment that needs automatic application updates, a consistent package format across desktop, server and IoT, and a centrally managed permission model for confined apps. Skip it for air-gapped environments that cannot reach the Snap Store for update delivery, or when GPL-3.0 is incompatible with redistribution requirements. Before deploying on IoT hardware, check the go-tpm2 and secboot dependency versions in go.mod to understand which TPM and EFI configurations the release you are running was built against.

Frequently asked questions

Official sources

1. canonical/snapd on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases