Choosing a security model


Snaps are containerised to ensure more predictable application behaviour and greater security.

Now that testing your app has proven it working outside of confinement, it’s time to turn confinement on so your app can be marked as “stable” when published in the Snap Store.

To confine your application, return to your snapcraft.yaml file and change the confinement value from devmode to strict:

confinement: strict

You will also likely need to specify some interfaces. These are declarations that tell the system to give permission for a specific task, such as accessing a webcam or binding to a network port. You can find a list of interfaces and their intended purpose in the reference documentation.

The interfaces are specified as a list of “plugs” in your snapcraft.yaml file, alongside your command definition. For example, if your application needs access to the Internet and to the user’s home directory:

    command: bin/offlineimap
    plugs: [home, network]

If you have multiple command definitions, you will need to provide separate plugs definitions for each.

Now that your snapcraft.yaml is updated for confinement, rebuild your snap. This is a quick process when only the confinement method has changed.

Install and test your rebuilt snap. If your app continues to work as expected, you’re ready for publishing in the Snap Store.


If your app has failed to start or behaves incorrectly, you may be missing some interfaces. Check journalctl -xe for a possible explanation, then refer to the interfaces in the reference documentation. Add any missing interfaces to your plugs definition, rebuild your snap, and test again.

If no explanation can be found, ask for assistance on the Snapcraft Forum. Be sure to include any relevant details, such as the contents of log files and any error messages printed on the terminal.

Next steps

Continue on to learn how to release your app in the Snap Store.

Releasing to the Snap Store
Proposed new documentation outline
Creating your developer account
Snap Documentation

@jdstrand this is a doc topic you might have further input on


Note that this path is not available in Debian-derived distros (/var/log/syslog), maybe using the journalctl command is more appropriate.


Thanks @Lin-Buo-Ren, fixed.


Maybe it’s best to also talk about scanlog instead of only journalctl -xe, since scanlog actually gives you hints about which interfaces or actions can fix security violations. scanlog is currently explained in the “Identifying missing interfaces” part of the “debugging building snaps” docs: