See below for a general overview of Snapcraft’s capabilities, and see Creating a snap for a more detailed look at the process, alongside a selection of self-contained examples for some popular languages and frameworks, including Go, Python and C/C++.

Working with snapcraft

At the heart of the snapcraft build process is a file called snapcraft.yaml. This file describes a snap’s build dependencies and run-time requirements, it integrates remote repositories and extensions, and runs custom scripts and hooks for better integration with CI systems.

Snapcraft 3.0, and later releases, are designed to use bases (see Base snaps) and Multipass to both simplify the build process and to to confine the build environment within a virtual machine. Confining the build in this way isolates potentially conflicting libraries and other files from your host system, and vice-versa.

Alternatively, if it better suits your processes, building directly on your system, or with either LXD or Docker, is also supported.

Creating snapcraft.yaml

To get started, run snapcraft init. This creates a buildable snapcraft.yaml template within a snap sub-directory relative to your current filesystem location. If the command cannot be found, make sure /snap/bin is on your PATH.

The typical snap build process centres on iterating over the configuration of parts, plugins and interfaces within this snapcraft.yaml file:

parts are the raw building blocks of a snap, used to collect and build binaries and their dependencies.

plugins are used within parts to better integrate projects using languages and framework.

interfaces enable resources from one snap to be shared with another, and with the host system.

The following lists how you might want to approach building a new snap for your application with snapcraft.yaml:

Building your snap

When you are ready to test the contents of snapcraft.yaml, simply run snapcraft --debug in the same directory where you initialised the snap,

The --debug argument isn’t necessary, but it helps hugely when testing a new snapcraft.yaml.

With --debug, if snapcraft encounters an error it will automatically open a shell within your snap’s virtual environment. You can then explore the build issue directly, working on your project within the parts directory, or the files being staged within prime, depending on the build stage when the error occurred.

Critically, you can update snapcraft.yaml outside of the build environment and run snapcraftwithin the build environment to incorporate any external changes and continue with the build. If there are no further errors, your snap will be built.

If you don’t have Multipass installed, snapcraft will first prompt for its automatic installation via a snap.

The build process will proceed through the Snapcraft lifecycle, installing and building your project’s dependencies, as described by your snapcraft.yaml. The time this takes will depend on the complexity of your project and the capabilities of your system.

After a snap has been built, it can be installed locally with the --dangerous and --devmode flags, enabling your unsigned and unconfined snap to be installed: