Apptainer vs werf

Apptainer shipped 1.5.0 in May after two release candidates, and has issued three point releases since. The major adds a subset of the Container Device Interface standard through --device and --cdi-dirs, selective mounting for Intel Gaudi accelerators, a buildkit: bootstrap that builds SIF images from a Dockerfile without Docker or Podman, and image pulls from an IPFS gateway. The point releases since have been almost entirely about the unprivileged build path — PRoot, mksquashfs and fuse2fs — plus a path-matching CVE in the suid limit container paths directive.

The 1.5 line is Apptainer catching up to how accelerators are actually exposed in 2026: CDI is the standard NVIDIA, Intel and others have converged on, and adopting it replaces per-vendor mount logic with a declarative spec the container runtime reads. The Gaudi support is the first vendor-specific case built on that footing. Separately, the buildkit bootstrap attacks the other friction point — needing a Docker daemon to build an image for a cluster that deliberately does not run one. The point-release churn shows where the cost lands: the bundled PRoot and squashfs tooling that makes unprivileged builds work is fragile across distributions, and 1.5.1 quietly documents that PRoot is no longer built on ppc, s390 or riscv at all.

Expect further CDI coverage as the obvious next step, since only a subset of the standard is implemented and each accelerator vendor currently needs its own flag. The unprivileged build path is the likely source of the next point release, given that three of the last three have been spent there.