Home

Welcome! These wiki pages include information that is primarily for Flatpak developers. However, this might be interesting if you want to know about how Flatpak works.

If you are new to Flatpak, check out the website. This includes getting started information as well as guides for application developers application developer documentation.

Goals

Flatpak has two main goals:

• Make it possible for third parties to create and distribute applications that work on multiple distributions.
• Run applications with as little access to the host as possible (for example user files or network access).

In the long run the sandboxing aspect is very important as it allow you to trust the applications less, which is important for users of third party applications. It also gives the user some level of protection against things that were historically not handled by the security system on Unix (which is primarily focused on protecting the system installation against the user).

The sandboxing is done with a set of technologies, including:

• cgroups
• namespaces
• Wayland (because X11 is inherently insecure)

However, sandboxing requires a lot of changes to applications and new APIs for sandboxed access to resources. So, in the short term the Flatpak initiative will focus on the first goal. Lennart Poettering has posted some documents (here and here) that describe how this could work, and we're using many of these ideas.

For details see sandbox implementation.

Project information

Who

Flatpak has been mainly driven by Alex Larsson, with some help from Matthias Clasen, David King, and others.

Where

Places where Flatpak discussion takes place:

• Mailing list: http://lists.freedesktop.org/mailman/listinfo/flatpak
• IRC: #flatpak on Freenode or #gnome-os on GimpNet

What

Releases will appear at: https://github.com/flatpak/flatpak/releases

Here is a list of outstanding tasks.

Technical notes

• Sandbox implementation
• Application and runtime metadata
• Application filesystem

Host system requirements

OSTree uses hardlinks, but has otherwise very little requirements on the underlying filesystem. The sandbox setup code is using kernel namespaces, the clone() syscall, seccomp filters, bind mounts, as well as cgroups and systemd --user. In order to provide access to services like X11, Wayland, D-Bus or PulseAudio, these services must be present in the user session, of course.