Apptainer: Application Containers for Linux

Original Article ↗ Hacker News Discussion ↗

Apptainer, the Linux Foundation–hosted successor to Singularity, is presented as a container system tailored for high‑performance computing: rootless by design, tightly integrated with host resources like GPUs and parallel filesystems, and distributed as single-file SIF images. Commenters contrast it with Docker, Podman, Flatpak, AppImage, and Nix-based approaches, noting advantages on multi-tenant HPC clusters without sudo, where networked storage, inode quotas, and security constraints make traditional OCI workflows awkward. Others question whether containers are the right abstraction at all for scientific and enterprise workloads, arguing that module systems, systemd-based isolation, or better OS-level primitives can sometimes offer simpler, more predictable environments.

Apptainer vs Other Container/Packaging Systems

  • Compared with Flatpak: Flatpak focuses on strong desktop sandboxing with fine‑grained permissions; Apptainer defaults to loose integration with the host (same UID, shared networking/PIDs, easy host file access) and can optionally add more isolation.
  • Discussion clarifies that OSTree vs “containers” really means OSTree vs OCI image format; both are about filesystem management, not containers themselves.
  • Apptainer supports its own SIF single‑file image format and can consume OCI images and CNI networking.
  • Compared with AppImage: AppImage is praised for including its own runtime, but also criticized as forcing developers to target very old distributions.
  • Nix and tools like nixery.dev are mentioned as alternative ways to get reproducible/ephemeral environments.

HPC and Scientific Computing Use Cases

  • Widely used on SLURM and other shared clusters where users lack sudo and Docker/Podman are often disallowed.
  • Strong presence in bioinformatics and general HPC as an alternative to compiling on the cluster or wrestling with system libraries.
  • Particularly valued for AI/ML on clusters: GPU passthrough “just works,” MPI and high‑speed interconnects integrate well, and --fakeroot allows unprivileged image builds.
  • Apptainer is effectively the continuation of the original Singularity project; Singularity CE is the fork. Containers are mostly interoperable, but behavior can differ (e.g., a reported timezone substitution bug in Singularity CE only).

Deployment, Storage, and Filesystem Considerations

  • SIF’s single‑file image is convenient on HPC where home and project dirs are network filesystems and local disks are small, ephemeral, or wiped between jobs.
  • Network filesystems (Lustre, NFS, etc.) and inode quotas strongly influence design: Apptainer images avoid inode exhaustion and don’t rely on overlayfs or local image stores.
  • Some argue Docker/Podman with registries and caching could also work at scale; others counter that per‑job, per‑user images and huge Python layers make that operationally painful.

Developer Workflow and Tooling Overlap

  • Apptainer is likened to Docker but rootless and tuned for CLI workloads; compared with Fedora Toolbox, which intentionally shares much of the host and is not security‑focused.
  • Commonly combined with conda for unprivileged package management.
  • Mac users can run Apptainer via Lima/VMs, but integration with IDEs is noted as weaker than Docker’s.

Critiques and Skepticism

  • Some find the project’s value vs rootless Podman/Docker unclear and wish messaging was sharper.
  • A silicon‑design team abandoned Apptainer after issues composing multiple toolchain containers, artifacts linking to hidden container libraries, and PATH confusion; they preferred traditional module systems (TCL/Lua).
  • Broader skepticism about containers appears: perceived fragility, complexity, “cheating” compared to clean toolchains, and discomfort with encryption/signing features that seem marketing‑driven.
  • Philosophical point: some argue process isolation should be a first‑class OS default rather than bolted on via userland container tooling.