What are conceptual and practical differences between containers (i.e. docker) and encapsulated packages (i.e. flatpack, snap)?

Question

I read often that both concepts are quite different, but I could not find a good explanation about where the differences lie. Both bundle dependencies and restrict talking to the outside world.

When should I pack my app in a container for deployment? When would encapsulated packages be preferable?

Answer 1

Flatpack offers a clues its FAQ includes:

Is Flatpak a container technology?

It can be, but it doesn't have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications.

In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and Rocket, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing.

Is Flatpak tied to Linux?

Yes. We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in. It may be possible to use equivalent technologies on other kernels, but that would be a non-trivial amount of work, and we don't consider this one of our priorities.

A container aims to offer isolation on any system which implements its runc/containerd protocol, and will be soon on Windows as well as Linux.

That differs from software packing format which are quite tied to the OS.
See "Flatpak, Appimage And Snap – How Do They Stack?".

Answer 2

Intro:

I believe for Developers, this is really a question about placing a bet on where the future of packaging their applications is headed, a bit like the VHS vs betamax debate in the early days of consumer video.

Flatpak, AppImage & Snap are all application containers- referred to also as "sandboxed" applications- which bundle dependencies, create isolation and promise portability.

If they all do (roughly) the same thing albeit slightly differently, then what's a rational basis for choosing one package format over another? Here's some considerations I've looked at when trying to make a decision about settling on a packaging format.

Choices:

I exclude Docker from the list below as it's considered to be a "process container" used predominantly to expose services to remote connections rather than providing local services.

• Flatpak: This is backed by RH, so they have the market clout to impose standards. HOWEVER: In RHEL 9, RH is still warning their customers not to use Flatpak on production systems. Flatpak will likely live well into the future, but there could be material changes to it before RH agrees to support it. Further, Flatpack standards vary between Fedora and RHEL. It appears by imposing a requirement to use RPMs, Flatpaks can be tracked along with non-flatpaks within the package database. This would be a good thing.

• Snap: This is backed by Canonical and Mark Shuttleworth described Snap as something akin to "Docker & apt" had a baby. They too have a huge amount of market cloud and can impose standards on us. And it is a standard that Canonical is currently willing to back in production systems unlike RH in respect to Flatpak. One thing I've remarked however doing some testing is that snaps are not visible when querying the package db: dpkg -l | grep snapName returns nothing. Further, although installing a snap also installs dependencies, uninstalling a snap doesn't auto-uninstall them. So we don't have a single source of Truth for the packaging state of our system which is not ideal. In respect to snaps being managed outside of the system package DB, Mark's analogy falls down. Another major variance I found with Snap was that unlike a standard package, not all architectures for a package were supported: "error: snap "slack" is not available on stable for this architecture (arm64) but exists on other architectures (amd64)". Finally, Snap has a huge number of packages available compared to both Flatpak & AppImage

• AppImage: This has no corporate backing- which is both a good and a bad thingy. I like the independence, but at the same time I can't ever see full integration into either RH's or Ubuntu's system package DB. Ideally I'd like any application container solution to be within the central package DB. So even were there a material qualatative difference, I feel having two separate package management systems is not a good thing. So this is really why I'd steer clear of it for my own purposes- not that it's "bad" per se, merely that I don't want a split-brain of package management.

Conclusion:

My own ideological bias favours Debian/Ubuntu distros as full-point upgrades are possible in-place which is not possible for RH & RH derivatives. So even were Flatpak marginally better than Snap as an application container (or "sandboxed application"), I'd still lean towards Snap as I don't have to throw the baby out with the bathwater if I'm running Linux on an IoT or other Edge device that I can't just wipe with impunity.

I suspect that this is a question developers have been wringing their collective hands over in respect to which camp they want to support. These are just some further, non-exhaustive considerations to weigh in making that choice.