Apptainer: Application Containers for Linux
43 comments
·June 26, 2025IshKebab
mbreese
I think of using Apptainer/Singularity as more like Docker than anything else (without the full networking configs). These are all issues with traditional Docker containers as well, so I’m not sure how you were using the containers or what you were expecting. For my workflows on HPC, I use apptainers as basically drop-in replacements for Docker, and for that, they work quite well. These biggest benefit is that the containers are unprivileged. This means you can’t do a lot of things (in particular complex networking), but it also makes it much more secure for multi-tenant systems (like HPC).
(I know Docker and Apptainer are slightly different beasts, but I’m speaking in broad strokes in a general sense without extra permissions).
cs_throwaway
Funny this is here. Apptainer is Singularity, described here:
https://journals.plos.org/plosone/article?id=10.1371/journal...
If you ever use a shared cluster at a university or run by the government, Apptainer will be available, and Podman / Docker likely won't be.
In these environments, it is best not to use containers at all, and instead get to know your sysadmin and understand how he expects the cluster to be used.
shortrounddev2
Why are docker/podman less common? And why do you say it's better not to use containers? Performance?
kgxohxkhclhc
docker and podman expect to extract images to disk, then use fancy features like overlayfs, which doesn't work on network filesystems -- and in hpc, most filesystems users can write to persistently are network filesystems.
apptainer images are straight filesystem images with no overlayfs or storage driver magic happening -- just a straight loop mount of a disk image.
this means your container images can now live on your network filesystem.
kinow
Apptainer and singularity ce are quite common in HPC. While both implementations fork the old singularity project, they are not really identical.
We use singularity in the HPCs (like Leonardo, LUMI, Fugaku, NeSI NZ, Levante) but some devs and researchers have apptainer installed locally.
We found a timezone bug a few days ago in our Python code (matplotlib,xarray,etc.), but that didn't happen with apptainer.
As the code bases are still a bit similar, I could confirm apptainer fixed it but singularity ce was still affected by the bug -- singularity replaces the UTC timezone file by the user's timezone, Helsinki EEST in our case in LUMI HPC.
throw0101c
> Apptainer and singularity ce are quite common in HPC. While both implementations fork the old singularity project, they are not really identical.
Apptainer is not a fork of the old Singularity project: Apptainer is the original project, but the community voted to change its name. It also came under the umbrella of the Linux Foundation:
* https://apptainer.org/news/community-announcement-20211130/
Sylabs (where the original Singularity author first worked) was the one that forked off the original project.
markus92
Luckily they’re still compatible with each others containers. Can use Apptainer to build the container then run it on Singularity and vice-versa.
evertheylen
If any developers are looking to isolate different dev projects from each other using containers, I wrote a tool for it (using podman), maybe someone finds it useful or can thrash its security.
Find the code on https://github.com/evertheylen/probox or read my blog post on https://evertheylen.eu/p/probox-intro/
maweki
Why didn't toolbox fit your needs? I found toolbox to be a very reasonable way to install development dependencies on a per project basis while not managing multiple hidden filesystems.
harel
Not a constructive comment, but I find the name "Apptainer" doesn't really work. Rolls funny on the tongue and feels just "wrong" to me.
Simran-B
Flatpak considers to move from OSTree to containers, citing the well-maintained tooling as a major plus point. How would that differ from Apptainers?
Imustaskforhelp
Maybe the idea is that flatpak can have better sandbox control over applications running in flatpak using xdg-dbus ie. you can select the permissions that you want to give to a flatpak application and so sometimes it can act near native and not be completely isolated like containers.
Also I am not sure if apptainers are completely isolated.
Though I suppose through tools like https://containertoolbx.org/ such point also becomes moot & then I guess if they move to container, doesn't it sort of become like toolbx?
To be honest, I think a lot of tools can have a huge overlap b/w them and I guess that's okay too
Tepix
I agree with Havoc, the message is unclear: Is Apptainer a replacement for Flatpack on the desktop, or is it targeting the server?
MillironX
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...
actinium226
I tried looking into this, but I do development work on Mac, which is not supported, and so it became a non starter.
mrweasel
To some extend I understand the problem that these solution are trying to address, I'm just not sure that simply stuff things into containers is really the right solution.
Perhaps the problems need to be addressed on a more fundamental level.
whatagreatboy
https://dl.acm.org/doi/10.1145/3126908.3126925
This paper might help
amelius
I have yet to see a container technology that doesn't break a myriad of things.
Hilift
I thought the "hardened images" were a step in the right direction. It's a pain to have to deal with vulnerabilities on ephemeral short-lived containers/instances. Having something hyper up to date is welcome.
https://www.docker.com/blog/introducing-docker-hardened-imag...
DrNosferatu
It is very handy in SLURM clusters and servers where you have no sudo.
Some attrition using it though: is there a good in-depth book about it?
floro
I used it on a SLURM cluster before. The documentation is done well and should be a good introduction. The only issue I had was that the cluster didn't have fakeroot or sudo, so I had to build the apptainer locally and transfer it to the server.
DrNosferatu
Exactly: in most HPC clusters / servers one has no sudo.
exabrial
Honestly switched to systemd isolation features (chroot, ro/rw mounts, etc) and never looked back.
We tried to use this on our compute cluster for silicon design/verification. We gave up in the end and just went with the traditional TCL (now Lua) modules.
The problems are:
1. You can't have apptainers that use each other. The most common case was things like Make, GCC, Git etc. If Make is in a different apptainer to GCC then it won't work because as soon as you go into Make then it can't see GCC any more.
2. It doesn't work if any of your output artefacts depend on things inside the container. For example you use your GCC apptainer to compile a program. It appears to work, but when you run it you find it actually linked to something in the apptainer that isn't visible any more. This is also a problem for C headers.
3. We had constant issues with PATH getting messed up so you can't see things outside the apptainer that should have been available.
All in all it was a nice idea but ended up causing way more hassle than it was worth. It was much easier just to use an old OS (RHEL8) and get everything to work directly on that.