Computing Library › HPC & Compute
HPC & Compute

Containers for HPC

Apptainer (formerly Singularity) packages an application with its dependencies into a portable image that runs unprivileged on shared clusters.

Why containers on clusters

Scientific software often depends on precise versions of compilers, libraries, and runtimes that may differ from what a cluster provides. A container bundles the application with its full user-space environment into a single image, so it runs the same way on a laptop, a cluster, and a cloud node. This makes results reproducible and shields the application from changes in the host software stack.

Why not plain Docker

Kronos motion — which application

The container runtime common in industry assumes a privileged daemon, which is a poor fit for multi-user HPC where users must not have root. Apptainer (formerly Singularity) was designed for this setting: images are single files, they run with the invoking user's identity (no privilege escalation), and by default the user's files and identity carry into the container. This security and simplicity model is why it dominates on shared research systems.

Getting performance through the container

A naive container would cut the application off from the fast interconnect and GPUs. HPC containers instead expose the host's MPI, InfiniBand, and GPU drivers into the image, so a containerized MPI job launched with the scheduler runs at native speed. The common practice is to build the image against a compatible MPI version and bind-mount the host's high-speed libraries at run time.

In practice

Packaging a Hyperion simulation toolchain, its exact compiler, MPI, and analysis libraries, into an Apptainer image lets the same validated software run across different clusters and be archived alongside the results. Anyone reproducing a study runs the identical stack, removing 'it worked on that machine' as a source of discrepancy.