Snapcraft top-level metadata


The top-level keys and values in snapcraft.yaml provide the snap build process, and the store, with the overarching details of a snap.

See Snapcraft app metadata and Snapcraft parts metadata for details on how apps and parts are configured within snapcraft.yaml.

Top-level details include a snap’s name, version and description, alongside operational values such as its confinement level and supported architecture.


Type: string

Incorporate external metadata via the referenced part.

See Using external metadata for more details.


Type: list[object]

List of build and run architectures.

For more details, see Architectures.


Type: list[string]

A list of features that must be supported by the core in order for this snap to install. For example to make the snap only installable on certain recent version of snapd(like 2.38) you can specify:

- snapd2.38

Some other values for specific features also exist, refer the featureSet list in overlord/snapstate/check_snap.go:


Type: string

A snap of type base to be used as the execution environment for this snap. See Base snaps for further details.


bare Empty base snap, useful for testing and fully statically linked snaps (e.g. busybox-static) (not yet supported)
core18 Ubuntu Core 18
core Ubuntu Core 16


Type: enum

Determines if the snap should be restricted in access or not.

Possible values are strict (for no access outside of declared interfaces through plugs), devmode (for unrestricted access) or classic. For more information, refer to Confinement.

Examples: strict, or devmode


Type: string

Multi-line description of the snap.

A more in-depth look at what your snap does and who may find it most useful.


Type: enum

Defines the quality grade of the snap.

Can be either devel (i.e. a development version of the snap, so not to be published to the stable or candidate channels) or stable (i.e. a stable release or release candidate, which can be released to all channels).

Example: [stable or devel]


Type: string

Path to icon image that represents the snap in the store pages and other graphical store fronts.

Note that the desktop menu does not use this icon. It uses the icon in the .desktop file of the application.

It is a relative path to a .png/.svg file from the source tree root. The recommended size is 256x256 pixels. Aspect ratio needs to be 1:1. Image size can vary from 40x40 to 512x512 px and the file size should not be larger than 256 KB.

Examples: _package_name_.svg, or snap/gui/logo.png


Type: string

A license for the snap in the form of an SPDX expression for the license.

In the legacy Snapcraft syntax (not using the base key), this key is only available through the passthrough key.

Currently, only SPDX 2.1 expressions are supported, refer snapd/licenses.go at master · snapcore/snapd for accepted expressions.

Examples: GPL-3.0, MIT, Proprietary


Type: string

The identifying name of the snap.

It must start with an ASCII character and can only contain letters in lower case, numbers, and hyphens, and it can’t start or end with a hyphen. The name must be unique if you want to publish to the Snap Store.

For help on choosing a name and registering it on the Snap Store, see Registering your app name.

Example: my-awesome-app


Type: type[object]

Attributes to passthrough to snap.yaml without validation from snapcraft.

See Using development features in snapcraft for more details.


Type: string

Sentence summarising the snap.

Max len. 78 characters, describing the snap in short and simple terms.

Example: The super cat generator


Type: string

The canonical title of the application, displayed in the software centre graphical frontends.

Max length 40 characters.

In the legacy Snapcraft syntax (not using the base key), this key is only available through the passthrough key.

Example: My Awesome Application


Type: enum

The type of snap, implicitly set to app if not set.

For more details, see: gadget, kernel, base.

Example: [app|core|gadget|kernel|base]


Type: string

A user facing version to display.

Max len. 32 chars. Needs to be wrapped with single-quotes when the value will be interpreted by the YAML parser as non-string.

Examples: '1', '1.2', '1.2.3', git (will be replaced by a git describe based version string)

Plugs and slots for an entire snap

Plugs and slots for an interface are usually configured per-app or per-daemon within snapcraft.yaml. See Snapcraft app metadata for more details. However, snapcraft.yaml also enables global plugs and slots configuration for an entire snap:


Type: dict

These plugs apply to all apps and differs from apps.<app-name>.plugs in that the type is in a dict rather than a list format, :(colon) must be postfixed to the interface name and shouldn’t start with -(dash-space).


Type: dict

A set of attributes for a plug.

Example: read attribute for the home interface.


Type: string

Value of the attribute.
Example: all for read attribute of the home interface.


Type: dict

A set of slots that the snap provides, applied to all the apps.


Type: dict

A set of attributes of the slot.


Type: dict

Value of the attribute.

Snapcraft app and service metadata
The snapcraft format
Snapcraft parts metadata
Snapcraft overview
Adding global metadata
Snap documentation
The Future of the Docker Snap
Snapcraft.yaml reference
Desktop files for menu integration

The separation of description to individual rows confuses me as the horizontal separator line is visible, hinting that the lower description belongs to another key.


Yes, I agree. It’s a bit of a compromise at the moment. The table layout on the final output has fixed equal divisions that makes more than 2 columns illegible (issue here:

We did experiment with other layouts (see List and table presentation ideas) and settled on the above as a stop-gap. I’ll try and push the table rendering issue up the priority list so we can do a better job of this and its related tables.


What’s the difference between this page and snapcraft-yaml-reference?

[legacy] Desktop App Support - GTK3 applications without extensions

Note that this page resolves to on the docs site. This page is meant just for defining metadata specifically for a snap - it is a subset of all the keys on the full YAML reference you linked to.


The documentation for base looks quite misleading on the docs:


Maybe use a table instead?


Good idea - thanks for the suggestion!