# Docker vs. Singularity for Bioinformatics Containerization Docker and Singularity both package a bioinformatics tool together with everything it needs to run, but Docker does this through a background service that normally requires administrator rights, while Singularity runs containers as ordinary user processes from a single portable file. The rule of thumb that settles most decisions: build and share images with Docker, run them on shared clusters with Singularity. If you must choose one tool for a system where many users lack administrator rights, choose Singularity. If you control your own hardware and want access to the largest library of ready-made images, choose Docker. Most productive labs end up using both, and this article shows you exactly where each one fits. ## Why Bioinformatics Needs Containerization Bioinformatics software has a dependency problem that is worse than in most other fields. A typical RNA-seq workflow might chain a read trimmer written in C, an aligner that needs a specific compiler version, quality control tools written in Java, and downstream statistics in R. Each tool expects particular versions of particular libraries, and those expectations collide. Installing tool A upgrades a library that breaks tool B. The system package manager offers one version of samtools while the paper you are reproducing used another. A **container** solves this by bundling an application with its entire runtime environment, including libraries, interpreters, and configuration, into an **image**, a frozen snapshot of that environment. Containers share the host kernel but nothing else, so two containers on the same machine can run incompatible versions of R side by side without conflict. An image is built in stacked **layers**, each layer capturing the filesystem changes from one build step, which makes images cheap to store, transfer, and rebuild. Images are distributed through **registries**, public or private servers that store tagged versions of images. The practical payoff shows up in two places. First, reproducibility. When a paper says the analysis used R 4.3.1 with Bioconductor 3.18, a container freezes that exact stack so the numbers can be regenerated years later. Second, transferability. Moving an analysis from a laptop to a 2,000-node cluster usually breaks hand-installed software. Containers break far less often, and when a tool does move, it moves as one file rather than as a page of install instructions. Real bioinformatics software makes the stakes concrete. Consider scAnnoX, an R package released in 2024 that integrates ten single-cell annotation algorithms, including SingleR, Seurat, sciBet, and scSorter, into one framework for comparing cell type annotations in single-cell RNA-seq data [1]. A package like that pulls in the dependency trees of ten separate tools, several of which live in the Bioconductor ecosystem and depend on specific R and Bioconductor release versions. Installing that stack by hand on three different machines produces three subtly different environments. A container produces the same environment every time. At the other end of the stack, deep learning tools carry their own burden of CUDA libraries, Python versions, and model weights. Garfield, a graph-based contrastive learning framework for integrating single-cell and spatial multi-omics data into shared embedding spaces, is a recent example of this class of method [2]. Reproducing a spatial atlas built with a framework like that means reproducing the exact combination of PyTorch, CUDA, and Python it was developed against, which is precisely the job containers were designed for. ## Docker on Its Own Terms ### How Docker works Docker, released in 2013, made containers mainstream and remains the default choice on personal machines and in continuous integration systems. It follows a client-server design. You type commands into the Docker client, and the client talks to a background service called the **daemon** (dockerd) that actually builds and runs containers. On Linux the daemon typically runs as root, which is the single fact that explains most of the friction between Docker and shared computing environments. Docker also ships a desktop application for macOS and Windows that runs a Linux virtual machine under the hood, since containers depend on Linux kernel features. Docker images follow the Open Container Initiative (OCI) specification, an industry standard that also defines the image format used by several other container engines. That standardization matters because it lets Singularity, Podman, and cloud platforms all consume the same images. You define an image with a **Dockerfile**, a plain text recipe of build instructions. A minimal example for two alignment staples: ```bash FROM ubuntu:22.04 RUN apt-get update && apt-get install -y \ bwa \ samtools \ && rm -rf /var/lib/apt/lists/* ``` `FROM` selects a starting image, `RUN` executes commands during the build, and each instruction creates a new layer. Build and run it: ```bash docker build -t mylab/aligners:1.0 . docker run --rm -v "$PWD":/data mylab/aligners:1.0 \ bwa mem /data/reference.fa /data/reads.fq > /data/aln.sam ``` The `-v` flag bind mounts your current directory into the container at `/data` so input files come in and output files go out. The `-rm` flag deletes the container when it exits. Note that `bwa mem` here runs inside the container while the redirect happens in your shell, so the output lands in your own directory. Push the result to a registry and anyone on any operating system can pull and run the identical stack: ```bash docker push mylab/aligners:1.0 ``` ### Docker pros and cons Docker's strengths are its enormous ecosystem, polished tooling, and first-class support in continuous integration platforms. Docker Hub hosts official images for R, Python, and Ubuntu, and community-built images for thousands of tools. Nearly every bioinformatics workflow manager can drive Docker directly. Its weaknesses follow from its design. The root daemon is a security concern on multi-user servers, which is why cluster administrators routinely refuse to install it. Docker Desktop, the graphical application for macOS and Windows, now requires a paid subscription at many organizations, so check the current licensing terms before standardizing on it in a company or institute. Writing into a running container is possible but ephemeral, and files a container writes as root can end up owned by root on your mounted directories, an annoyance that surprises new users. ## Singularity (Apptainer) on Its Own Terms ### How Singularity works ![Diagram of apptainer pull turning a Docker registry image into one SIF file, then apptainer exec running it as your own user process.](/article-images/illustrations/containerization-bioinformatics-docker-singularity-docker-pull-to-sif.webp) Singularity was created at Lawrence Berkeley National Laboratory specifically for high-performance computing (HPC) environments, clusters where hundreds of researchers share one machine and nobody has administrator rights. The project joined the Linux Foundation and was renamed **Apptainer**, which is now the primary name and the one used by most current documentation. Sylabs maintains a community edition called SingularityCE, and the two remain nearly identical in daily use. Throughout this article the concepts apply to both, and I use the Apptainer command names since they are what a new installation will give you. Three design decisions set Apptainer apart from Docker. First, no daemon. An Apptainer container is an ordinary process started by you, the user, using a Linux kernel feature called **user namespaces** that lets an unprivileged process run with a modified view of the system. There is no root-owned service brokering access, so cluster administrators can install Apptainer once system-wide and every user can run containers immediately. Second, images are single files. Apptainer packages an image into a **SIF** file (Singularity Image Format), one self-contained file you can copy to scratch storage, archive, or email to a collaborator. This fits HPC storage realities, where shared filesystems are the norm and layered image caches are unwelcome. Third, the default boundary between container and host is thin. By design, Apptainer mounts your home directory, the current directory, and `/tmp` into the container automatically, and it inherits your user identity, so files created inside the container are owned by you. That convenience cuts both ways, a point that returns in the mistakes section. Getting a tool is often one command, because Apptainer can convert Docker images on the fly: ```bash apptainer pull fastqc.sif docker://quay.io/biocontainers/fastqc:0.11.9 apptainer exec --bind /scratch:/scratch fastqc.sif \ fastqc /scratch/reads.fastq.gz ``` The BioContainers project, which packages bioinformatics software as OCI images on registries such as Quay, publishes tags in a specific format that includes a build identifier, so check the registry for the exact tag of the version you need rather than relying on a shortened tag. `apptainer exec` runs a single command inside the image, `apptainer shell` gives you an interactive shell, and `-bind` adds a host directory to the container's filesystem. Building your own image needs a definition file (the Apptainer equivalent of a Dockerfile). Because building requires privileges that a plain user does not have, the usual pattern is to build with the `-fakeroot` option where the administrator has enabled it, or to build a writable **sandbox** directory and convert it, or to let the Apptainer remote builder do the work. On many clusters the simplest honest path is to pull a prebuilt Docker or BioContainers image and skip local builds entirely. GPU access is one flag: ```bash apptainer exec --nv garfield_env.sif python run_garfield.py ``` The `-nv` flag maps the host NVIDIA driver and libraries into the container, so the CUDA stack inside the image only has to match the CUDA runtime level, not the driver, which is managed by the system administrators. ### Pros and cons Apptainer's strengths are unprivileged execution, single-file portability, automatic access to home and scratch directories, clean integration with batch schedulers, and ownership of output files by the invoking user. Its weaknesses are a smaller ecosystem of its own (though it borrows Docker's), a build workflow that is more awkward than Docker's, and automatic filesystem mounts that can silently alter the environment inside the container if you are not paying attention. ## Side-by-Side Comparison This table is the core of the decision. Read it with your own situation in mind, because the "better" column depends entirely on where you run your work. | Criterion | Docker | Singularity (Apptainer) | |--|--|--| | Administrator rights needed to run | Usually yes, daemon runs as root (a rootless mode exists but needs setup) | No, ordinary users run containers via user namespaces | | Architecture | Client talks to a root-owned daemon | Daemon-less, containers are user processes | | Image format | OCI layers in a local cache, distributed via registries | Single SIF file, plus OCI layer caches | | Typical home turf | Laptops, workstations, CI pipelines, cloud servers | HPC clusters, shared multi-user servers | | Ecosystem | Largest, Docker Hub plus Quay and GitHub registries | Smaller natively, but consumes Docker and BioContainers images directly | | Building images | First-class, Dockerfile, fast layered caching | Possible via definition files, fakeroot, or remote builder, more friction | | GPU support | Via nvidia-container-toolkit, configured by admin | Built-in `-nv` flag, works without admin involvement | | Writable container filesystem | Yes, ephemeral per container | No, image is read-only, writable overlay optional | | Default filesystem access | Nothing mounted unless you ask | Home, current directory, and /tmp mounted automatically | | Files created by containers | Often owned by root on mounts | Owned by the invoking user | | Batch scheduler fit | Poor, schedulers forbid root daemons | Excellent, native fit with SLURM and PBS scripts | | MPI parallel jobs | Awkward | Supported through a hybrid container-host model | | Security model on shared servers | Weak by default, the daemon is a shared root service | Strong by default, users stay unprivileged | | Licensing | Engine free, Docker Desktop needs paid subscriptions at many organizations | Free and open source under the Linux Foundation | Three rows deserve comment. The permissions row decides most cluster deployments on its own. The image format row explains why Archival copies of Apptainer images are genuinely frozen artifacts while a Docker tag can point to different bytes tomorrow. The filesystem rows explain most day-to-day behavior differences you will notice within your first week of using either tool. ## Choosing Between Docker and Singularity: The Criteria That Matter ### Permissions and the daemon problem The root daemon is the axis on which almost everything else turns. On a laptop you own, the daemon is a non-issue and Docker's convenience wins. On a shared cluster, a root daemon is a policy problem and usually a hard no from the systems team. Apptainer was engineered around this constraint, and it shows in every design decision. Ask one question first: who administers the machine I will actually run on, and will they install a root daemon? If the answer is no, the choice is made for you. ### Reproducibility ![Four cards covering pinning by digest, not using the latest tag, archiving the SIF file, and saving the Docker image.](/article-images/illustrations/containerization-bioinformatics-docker-singularity-reproducibility-practices.webp) Neither tool is automatically reproducible, and a common misconception says otherwise. A Docker image tagged `latest` can change under you, and even a specific tag like `ubuntu:22.04` receives security updates that change its contents. Reproducibility comes from pinning, not from the engine. Pin base images by digest (the content hash, for example `ubuntu:22.04@sha256:...`), record the digest in your methods, and rebuild nothing silently. With Apptainer, a pulled SIF file is itself a frozen artifact, which is a genuine practical advantage for archiving. Convert and archive a SIF at the time of publication, store it with your data, and the exact bytes persist. With Docker, `docker save` produces an equivalent archive tarball. Both engines support reproducibility, Apptainer just makes the frozen file the default unit of distribution. ### GPUs and specialized hardware Deep-learning methods now sit at the center of many analyses. Garfield, for instance, learns shared embedding spaces across transcriptomic, epigenetic, and proteomic single-cell and spatial data using graph contrastive learning, and applying it to tumor microenvironment data means running substantial neural network training [2]. That workload lives or dies by GPU access. Docker reaches GPUs through nvidia-container-toolkit, which works well but is administered at the system level. Apptainer's `-nv` flag works out of the box for any user once NVIDIA drivers exist on the host. For GPU work on shared machines, Apptainer is the path of least resistance. The one persistent trap is the CUDA compatibility relationship between the host driver and the toolkit version inside the image, which is a real source of "works on the GPU node, fails on the CPU node" bugs in both engines. ### Filesystem behavior and I/O performance Docker gives you nothing unless you mount it. Apptainer gives you everything by default. The Docker model is explicit and safe, the Apptainer model is convenient and occasionally surprising, because your real home directory, with all its conda environments and shell configuration, is visible inside the container and can shadow the container's own files. Apptainer also tends to perform well on parallel filesystems such as Lustre and GPFS, which dominate HPC storage, since it reads the image as a file rather than unpacking layers into a per-user cache. Docker's layer cache lives in daemon-managed storage that can grow silently into hundreds of gigabytes on a workstation. ### Ecosystem and shared images Docker wins on raw availability. The best bioinformatics software often arrives as a Docker image first, and BioContainers, the community effort that auto-builds container images from the Bioconda package repository, publishes images consumable by both engines. Quay.io hosts much of the BioContainers output. If a tool you need exists only as a Dockerfile on GitHub, Docker builds it in one command, and Apptainer can then convert the result. In practice the ecosystem gap is smaller than it looks, since `apptainer pull docker://...` turns Docker's library into Apptainer's library. What Docker has that Apptainer lacks is tooling depth, richer plugin ecosystems, and smoother continuous integration integration on platforms built around Docker. ### Workflow managers and pipeline integration Modern pipelines rarely call containers by hand. Nextflow, Snakemake, CWL-based engines, and WDL runners all accept a container directive per process and swap engines with a profile flag, so the same pipeline runs with Docker on your laptop and with Apptainer on the cluster. This is the single best reason to learn both tools lightly rather than mastering one: the pipeline abstraction makes the engine a configuration detail. When you review a workflow's documentation, check which engines its profiles enable before assuming you need a specific one. ### Security on shared servers On a multi-user machine, the threat model matters. A root daemon means any user who can talk to it can potentially mount host filesystems and escalate privileges, which is why hardened deployments restrict Docker socket access. Apptainer's unprivileged design means a user can only do inside a container what they could do outside it, which cluster security teams find far easier to accept. If you administer a server that colleagues share, Apptainer is the defensible default. If colleagues need Docker specifically, look at rootless Docker or Podman, an OCI-compatible engine that runs daemon-less much like Apptainer. ### Licensing and cost Both engines are open source at the engine level. The cost question concentrates on Docker Desktop, which is free for individuals and small organizations but requires paid subscriptions for larger companies, with terms that have changed more than once. Apptainer carries no such commercial licensing layer. For a university lab this is usually moot, for a company it can decide the build-versus-buy conversation around developer tooling. ### Other options worth knowing The two-engine framing hides a wider field. **Podman** runs rootless and speaks the Docker command line almost perfectly, making it a strong choice on Linux workstations where you want Docker habits without the daemon. **Charliecloud** and **Shifter** are HPC-native container systems used at some large computing centers, and you may simply be told which one your allocation uses. Apptainer remains the most broadly installed option on academic clusters, so it is the one to learn by default. ## Worked Scenarios ### Scenario 1: A benchmarking project on your workstation You are comparing cell type annotation methods on a [single-cell RNA-seq dataset](/blog/guides/single-cell-rna-seq-dataset). This is exactly the problem scAnnoX addresses, integrating ten annotation algorithms, including reference-based methods like SingleR and marker-based ones like scCATCH, into one comparative framework [1]. A fair bioinformatics tools comparison like this has a hidden requirement: every algorithm must run against the same R version, the same Bioconductor release, and the same reference annotations, or part of any performance difference is an environment artifact rather than a real difference between methods. The clean pattern is one container per tool, each pinned to the R version the tool was developed against, orchestrated by a script that calls each container in turn. On your own workstation, Docker makes building those images pleasant. Write a Dockerfile per method starting from a pinned R base image, install the specific package versions, build, and run each annotation inside its own image. When a reviewer asks how you kept the comparison fair, the Dockerfiles are the answer. ### Scenario 2: An HPC cluster with SLURM Your lab has an allocation on a university cluster running SLURM, the batch scheduler that hands out compute nodes to jobs. You cannot install Docker and nobody expects you to. The workflow looks like this: ```bash apptainer pull samtools.sif docker://quay.io/biocontainers/samtools:1.19.2 ``` Copy the SIF file to your scratch directory, then reference it from a batch script: ```bash #!/bin/bash #SBATCH --job-name=samtools #SBATCH --mem=8G #SBATCH --time=2:00:00 module load apptainer apptainer exec --bind /scratch/$USER:/scratch/$USER \ /scratch/$USER/samtools.sif \ samtools sort -o /scratch/$USER/aln.sorted.bam /scratch/$USER/aln.bam ``` The scheduler runs your script on a compute node, Apptainer starts as your unprivileged user, your scratch space is bind-mounted, and the sorted BAM file lands in your directory owned by you. No administrator conversation required beyond asking that the Apptainer module exist, which on most clusters it already does. ### Scenario 3: A GPU deep-learning analysis of spatial data Your project involves spatial [transcriptomics](/knowledge/bioinformatics/modern-transcriptomics-bulk-single-cell-spatial) and a geometric deep-learning method. Garfield exemplifies the category, a framework that uses graph-based contrastive learning to embed cells from diverse single-cell and spatial technologies into a shared space and to identify tissue niches, demonstrated across mouse brain data and tumor microenvironment datasets [2]. Tools in this class expect a CUDA-enabled PyTorch stack, and the combination of driver, toolkit, and library versions is fragile to hand-install. On the cluster, the path is to pull or build a GPU-enabled image containing the framework and its dependencies, then submit with the GPU flag: ```bash apptainer exec --nv /scratch/$USER/garfield_env.sif \ python run_embedding.py --input /scratch/$USER/data ``` The `-nv` flag wires the container to the node's GPUs. On a cloud server you control, the same image runs under Docker with the GPU runtime enabled. Build once, run in either engine. ### Scenario 4: A shared multi-institution pipeline You are contributing to a pipeline that several institutions run. The durable pattern, used by large community pipeline collections, is a workflow manager with engine profiles. The pipeline declares a container image per process, and a configuration switch selects `docker` when you develop locally and `apptainer` when it runs on each institution's cluster. Every site gets identical tool versions without identical installation effort, and the images themselves come from a pinned registry where each release is tagged and hashed. This scenario is where containerization stops being a personal convenience and becomes infrastructure, and it is the pattern worth building toward even for small labs, because it costs little up front and pays off the first time a collaborator's cluster differs from yours. ## Common Mistakes and Limitations 1. **Using the `latest` tag.** An image tagged `latest` is a promise about convenience, not about content. Pin a specific version tag, and for published work pin the digest. Six months from now, `latest` will not mean what it means today. 2. **Assuming Apptainer makes things reproducible automatically.** The SIF file is a stable artifact only if you archive it. If you re-pull the same tag next year you may get a rebuilt image. Freeze the file and record its hash at the time you publish. 3. **Letting your home directory sabotage the container.** Apptainer mounts your real `$HOME` by default. If your home contains a conda installation or Python packages, they can shadow the ones inside the image and change behavior. When a container misbehaves in ways that defy its contents, rerun it with `-contain` and a clean environment, which suppresses those automatic mounts. 4. **Writing results inside the container and losing them.** With Docker, anything written to the container's own filesystem vanishes when the container exits unless you mounted a volume. Write outputs to mounted directories, always. 5. **Root-owned output files from Docker.** A container running as root that writes into a bind-mounted directory can leave files owned by root that you cannot delete. Run containers with `-user` matching your numeric user ID when this matters, or fix ownership afterward with administrator help. 6. **Trusting unknown registry images.** Public registries contain contributed images of varying quality, and compromised images with cryptomining payloads are a documented problem. Prefer official images, BioContainers images, or images your own group built. Treat a random Docker Hub image the way you would treat a random binary download, because that is what it is. 7. **GPU and CUDA mismatches.** The container carries the CUDA toolkit, the host carries the driver, and the two must be compatible. When a GPU job fails with a library error, check this relationship before rewriting code. Driver updates on the cluster can break previously working images. 8. **Image and cache bloat.** Docker layer caches and Apptainer pull caches grow without obvious warning. Prune periodically (`docker system prune`) and keep SIF files in scratch or project storage rather than home directories, which are usually quota-limited. 9. **Fighting the scheduler.** Do not attempt to run the Docker daemon on a cluster login node. If your workflow manager suggests it, the correct fix is its Apptainer or Singularity profile. 10. **Conflating Apptainer and old Singularity documentation.** Pre-rename Singularity 2.x documentation describes a setuid security model that modern versions dropped. When reading older instructions, confirm they match Apptainer or SingularityCE 3.x, where user namespaces are the mechanism and many flags behave differently. 11. **Expecting containers to fix bad pipeline logic.** A container guarantees the environment, not the analysis. Version-pinned software running a mis-specified model produces reproducible wrong answers. ## A Practical Decision Framework 1. Identify where the compute will actually run. Laptop or cloud server you control points to Docker. Shared cluster points to Apptainer. 2. Ask your system administrator what is installed. Many clusters already have Apptainer as a module, which settles the question before it becomes a debate. 3. Separate building from running. Building images is easiest in Docker, running them is easiest in Apptainer. The conversion between the two is a one-line pull, so there is no need to force one tool to do both jobs. 4. Pin everything. Version tags, digests, and archived SIF files are what make work reproducible, regardless of engine. 5. Route both engines through a workflow manager if your analysis has more than a handful of steps. The engine then becomes a profile setting rather than a lifestyle choice. 6. Revisit only when forced. Docker and Apptainer are mature, stable choices. The marginal gains from switching engines are small compared with the gains from pinning versions and documenting your environment. ## Frequently Asked Questions ### Is Apptainer just the new name for Singularity? Yes. The project was renamed Apptainer when it joined the Linux Foundation, and Sylabs separately maintains SingularityCE. Commands, file formats, and concepts are effectively the same, and current documentation uses the Apptainer name. ### Can I run a Docker image with Singularity or Apptainer? Yes. `apptainer pull docker://registry/image:tag` downloads and converts a Docker image into a SIF file, so the Docker ecosystem is available from Apptainer. The conversion happens at pull time and the resulting SIF is then your stable copy. ### Do I need administrator rights to run containers? With Docker, usually yes, because the daemon runs as root, although a rootless mode exists with extra setup. With Apptainer, no. Unprivileged users run containers through Linux user namespaces, which is why Apptainer is standard on shared clusters. ### How do I give a container access to GPUs? With Apptainer, add the `-nv` flag, which maps the host NVIDIA driver into the container. With Docker, the host needs nvidia-container-toolkit installed, after which you enable GPU access at run time. In both cases the host driver and the CUDA version inside the image must be compatible. ### Is a Singularity image automatically more reproducible than a Docker image? No. Reproducibility comes from version pinning and archiving, not the engine. A SIF file is a convenient frozen artifact once you save it, and `docker save` provides the equivalent for Docker. An unpinned tag is unreproducible in either tool. ### Should I use Conda instead of a container? Conda solves package installation but not the operating system layer, so system libraries, compilers, and CUDA can still drift between machines. Containers capture the whole environment. The two combine well, with conda environments installed inside container images during the build. ## Sources 1. [scAnnoX: an R package integrating multiple public tools for single-cell annotation.](https://pubmed.ncbi.nlm.nih.gov/38560451/) 2. [Graph-based contrastive learning enables unified integration and niche transfer across single-cell and spatial multi-omics.](https://pubmed.ncbi.nlm.nih.gov/42608748/)