Apptainer — Containers That HPC Clusters Allow

What Apptainer is

Apptainer is a container system built for high-performance computing. It was called Singularity until the project moved to the Linux Foundation, and you will still meet both names on cluster documentation and in older papers.

It exists because of one specific incompatibility. Docker requires a daemon running with root privileges, which means any user who can run a container can effectively become root on the host — unacceptable on a shared machine with hundreds of users and other people’s data. Apptainer runs containers as you, with your permissions, with no privileged daemon. That single architectural difference is why every major academic HPC centre supports Apptainer and almost none support Docker, and it is the entire reason this tool is in the directory.

Why researchers use it

Clusters actually allow it — the only container runtime you can reliably expect to be available on academic HPC.
Single-file images — a container is one .sif file you scp to the cluster like any other file, with no registry, no daemon, and no layer cache to reason about.
It reads Docker images — apptainer pull docker://python:3.12-slim converts an existing image, so the whole Docker ecosystem is available to you.
Your filesystem is just there — home directory and often scratch are mounted automatically, so the container sees your data without volume-mount incantations.
It runs your user, not root — files written inside the container belong to you, which removes the permissions mess that catches Docker beginners.

Where it fits in a research workflow

Apptainer is the bridge between the machine you develop on and the machine you compute on. The standard pattern — and the one in local to cluster workflow — is to build the image where you have root (your laptop, a VM, or a build service), copy the single .sif to the cluster, and run your jobs inside it.

From there it composes with the rest of the HPC stack: SLURM submits the job, Snakemake or Nextflow invokes the container per rule or process, and a conda environment usually lives inside the image — the pattern in Anaconda to Apptainer. At the end, the .sif is also your archival artefact: deposit it or its recipe alongside the paper, because a container that still runs is worth more to a future reproducer than an environment file that no longer resolves.

Getting started

An afternoon, and check the cluster before you build anything.

Check what your cluster already has: module avail apptainer or module avail singularity. Most academic HPC centres provide one, and the module name tells you which era of documentation applies to you.
Pull an existing image before building your own: apptainer pull docker://python:3.12-slim. Running something inside it teaches you the mental model in ten minutes.
Run your pipeline: apptainer exec container.sif python analysis.py — your home directory is already visible from inside.
The step people skip: write a definition file rather than building interactively. An image you assembled by hand is unreproducible, which defeats the purpose; a .def file in your repository is a recipe someone can rebuild and audit.

Apptainer vs the alternatives

Alternative	Does it better	Pick it if
Docker	Tooling, documentation, ecosystem, and local development	You never touch a shared cluster
conda	Far less setup for a working scientific environment	You need it working today, on one machine
Snakemake / Nextflow	Orchestrating the jobs that run inside containers	You have many steps, not one environment
Cluster modules	Zero effort — someone else maintains the software	The versions available happen to be the ones you need

Apptainer’s advantage is narrow and decisive: it is the one that runs where your compute is. Everywhere else, Docker is better supported.

Cost, licensing, and your data

Free and open source under a BSD-style licence, hosted by the Linux Foundation — the governance move that took it out of a single company’s hands and is a good sign for a tool you want to still work in a decade.

The governance property that matters for research is the permission model. Because Apptainer runs as you and not as root, a container cannot reach anything on the cluster filesystem that you could not reach anyway. For work under a data agreement on a shared system, that is a meaningful and stateable property: containerising your analysis does not widen your access. It also means the usual container caution applies in reverse — the image sees your home directory by default, so if you build an image from a directory containing sensitive data, check what you have baked in before sharing the .sif.

The honest review

Strengths. Apptainer is the only way most researchers get containerised reproducibility on the hardware they actually use. The single-file .sif is an underrated design choice: it copies, archives, and versions like a document rather than requiring a registry, which fits how research artefacts are actually stored. And old images keep working — five-year-old .sif files still run, which is precisely the standard “reproducible after publication” demands and precisely what environment files fail.

Limitations. Building usually needs root or --fakeroot support, which you will not have on the cluster — so you need a Linux machine, a VM, or a remote build service, and on macOS or Windows that means an extra layer before you can build anything. Documentation and community answers are far thinner than Docker’s, so unusual problems take longer to solve. The Singularity/Apptainer split left the internet full of instructions for a tool with a different name and occasionally different flags. And the automatic home-directory mount, convenient as it is, quietly undermines isolation: your container can see host files, which means an analysis can accidentally depend on something outside the image and appear reproducible when it is not.

Verdict. Adopt it if any part of your work runs on a shared cluster — there is no alternative, and learning it is not optional. Skip it if all your computing is local, where Docker’s tooling and documentation are simply better. The condition that flips the answer is a single question: do you have an HPC account?

When NOT to use this Do not assume a container that works because your home directory is mounted is actually reproducible. Apptainer mounts host paths by default, so a script that quietly reads a config file, a dataset, or a Python package from outside the image will run fine for you and fail for everyone else — while looking containerised. Test with --containall or on a clean account before you publish the image, and put the definition file in your repository so the build is auditable.

Common questions

Is Apptainer the same as Singularity?

Effectively yes — Apptainer is the renamed continuation of the Singularity project under the Linux Foundation. Some clusters still provide a singularity module, and older documentation uses that name; the commands are largely compatible, but check which your cluster has before following a tutorial.

Can I use Docker images with Apptainer?

Yes. apptainer pull docker://image:tag converts a Docker image into a .sif file. This is the normal workflow: build or find a Docker image, convert it, copy the single file to the cluster.

Do I need root to use Apptainer?

Not to run containers — that is the whole point, and it is why clusters permit it. Building an image typically does require root or --fakeroot support, so most people build on a laptop or VM and copy the resulting .sif to the cluster.