Docker is excellent for developer environments and cloud-native services. It is usually the wrong abstraction for shared HPC clusters. The issue is not that Docker containers are technically impossible on supercomputers. The issue is that the operational model conflicts with how HPC systems are administered.
Apptainer, formerly known as Singularity, fits those environments because it keeps the user identity and privilege model aligned with the host.
Image source: Apptainer.
Why Docker Breaks the HPC Contract
Traditional Docker workflows rely on a daemon and often privileged operations that cluster administrators do not want exposed across multi-tenant infrastructure. On a shared Slurm cluster, the platform assumption is simple: users submit jobs, but they do not receive a path to generalized privilege escalation.
Apptainer documents the opposite approach: users remain the same inside and outside the container, and the runtime is designed for shared resources.
User Identity Matters
In HPC, the security boundary is closely tied to Unix identity, quotas, and scheduler policy. If a container runtime weakens that boundary, the cluster becomes harder to govern.
A simplified way to express the risk is:
$$ Risk_{runtime} \propto Privilege\ Elevation \times Shared\ Surface $$
Reducing privilege elevation reduces the entire class of administrative objections.
Mounts and Filesystems Are Not a Detail
Many bioinformatics workflows depend on shared filesystems, reference genomes, scratch directories, and scheduler-managed working paths. Container success therefore depends on mount semantics, not just image portability.
Apptainer explicitly supports bind paths and mount controls in a way that matches HPC execution patterns. That is why it feels natural on Slurm while Docker often feels bolted on.
A Typical Slurm Pattern
Instead of running a daemonized container service, you usually execute the container directly inside the job allocation.
#!/bin/bash
#SBATCH --job-name=qc
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
apptainer exec \
--bind /scratch:/scratch \
fastqc.sif \
fastqc /scratch/sample.fastq.gz
This matches the cluster model cleanly: the scheduler owns resource assignment, the container owns software encapsulation, and the user identity remains stable.
Why This Matters for Bioinformatics
Bioinformatics tools are dependency-heavy and often fragile across environments. Containers solve that reproducibility problem, but only if the runtime itself is acceptable to the platform team.
That is why the winning pattern on HPC is usually:
- build with Docker or OCI when convenient
- convert or pull into Apptainer-compatible images
- execute through Slurm with explicit mounts
Apptainer itself is designed to interoperate with Docker and OCI sources, so teams do not lose ecosystem compatibility.
Final Takeaway
Docker fails in HPC mostly because it optimizes for a different trust and operations model. Singularity and Apptainer succeed because they were shaped around shared scientific infrastructure, mounted filesystems, and scheduler-governed execution.
If the workload lives on Slurm, the question is usually not which container format is fashionable. The question is which runtime preserves security, portability, and operational sanity.