Apptainer: Application Containers for Linux

I agree with Havoc, the message is unclear: Is Apptainer a replacement for Flatpack on the desktop, or is it targeting the server?

Server - but this is kind of a wrong question. Apptainer is for running cli applications in immutable, rootless containers. The closest tool I can think of is Fedora Toolbx [1]. Apptainer is primarily used to distributing and reusing scientific computing tools b/c it doesn't allow root, doesn't allow for changes to the rootfs in each container, automatically mounts the working directory and works well with GPUs (that last point I can't personally attest to).

[1]: https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...

> Apptainer is for running cli applications in immutable, rootless containers.

What's the appeal of using this over unshare + chroot to a mounted tarball with a tmpfs union mount where needed? Saner default configuration? Saner interface to cgroups?

Apptainer, like the vast majority of container solutions for Linux, take advantage of Linux namespaces. Which is a lot more robust and flexible then simple chroot.

In Linux (docker, podman, lxc, apptainer, etc) containers are produced by combining underlying Linux features in different way. All of them use Linux namespaces.

https://www.redhat.com/en/blog/7-linux-namespaces

When using docker/podman/apptainer you can pick and choose when and how to use namespaces. Like I can use just use the 'mount' namespace to create a unique view of file systems, but not use the 'process', 'networking', and 'user' namespaces so that the container shares all of those things with the host OS.

For example when using podman the default is to use the networking namespace so it gets its own IP address. When you are using rootless (unprivileged) mode it will use "usermode network" in the form of slirp4netns. This is good enough for most things, but it is limited and slow.

Well I can turn that off. So that applications running in a podman container share the networking with the host OS. I do this for things like 'syncthing' so that the container version of that runs with the same performance as non-containered services without having to require special permissions for setting up rootful network (ie: macvlans or linux bridges with veth devices, etc) )

By default apptainer just uses mount and user namespaces. But it can take advantage of more Linux isolation features if you want it to.

So the process ids, networking, and the rest of it is shared with the host OS.

The mount namespace is like chroot on steroids. It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.

And it makes it easier to take adavantage of container image formats (like apptainer's SIF or more traditional OCI containers)

This is Linux's approach as opposed to the BSD one of BSD Jails were the traditional limited Chroot feature was enhanced to make it robust.

I'm aware of all of this, it might not be clear if you've not used it directly yourself, but unshare(1) is your shell interface to namespaces. You still need to use a chroot if you want the namespace to look like a normal system. Just try it without chrooting:

unshare --mount -- /bin/bash

> It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.

Same is true for namespaces actually.

https://www.helpnetsecurity.com/2025/05/20/containers-namesp...