Apptainer (formerly Singularity) is the container runtime on the scicompute cluster. It lets you run software packaged as a container — including images built for other Linux distributions or pulled straight from Docker Hub — without needing root and without Docker.

Use containers when you need software that won’t install cleanly on the cluster’s OS, want a reproducible environment, or want to run a published image (e.g. from NVIDIA NGC, BioContainers, or Docker Hub).

Quick start

Apptainer is installed on every compute node and is always on your PATH. Load the module to get the recommended cache settings:

module load apptainer

Pull an image and run a command in it:

# Pull a published image to a .sif file
apptainer pull docker://biocontainers/blast:2.2.31

# Run a command inside it
apptainer exec blast_2.2.31.sif blastp -help

# Or get an interactive shell inside the container
apptainer shell blast_2.2.31.sif

That’s the whole loop for most users: pull once, then exec/shell.

Where your files are inside a container

Apptainer automatically makes your data visible inside the container. These paths are the same inside as outside:

You do not need to create mount points in the container or pass --bind for these — they just work. If you need some other host path inside the container, add it explicitly:

apptainer exec --bind /some/other/path my-image.sif my-command

Using a GPU

On GPU nodes, add --nv to give the container access to the host GPUs and NVIDIA driver:

apptainer exec --nv docker://nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

--nv works with exec, shell, and run. Inside the container, nvidia-smi should list the GPUs allocated to your job. Request GPUs through Slurm as usual (--gres=gpu:1); --nv only exposes the GPUs your job already has.

Refreshing an image

To update a .sif to the latest version of its source image:

apptainer pull --force my-image.sif docker://repo/image:tag

This re-checks the registry and only re-downloads if the image actually changed — so it’s quick (often instant) when nothing’s new.

Running containers in batch jobs

Containers work normally in Slurm batch scripts:

#!/bin/bash
#SBATCH --partition=general-gpu
#SBATCH --gres=gpu:1
#SBATCH --mem=16G
#SBATCH --time=2:00:00

module load apptainer
apptainer exec --nv my-image.sif python train.py

Tips and gotchas

• Pull big images once, keep the .sif. A pulled .sif is a single file you can reuse across jobs and nodes. Keep it in your scratch or project space and exec it directly — no need to re-pull each job.
• Disk space during a pull. Pulling an image unpacks it temporarily in node-local /tmp. A large image (e.g. an NGC PyTorch/TensorFlow image) can briefly use 30–60 GB of temporary space. If a pull fails with a “no space” error, the image is too big for that node’s local disk — pull it on a node with more local scratch, or ask SCI IT.
• The cache lives in your scratch. With the module loaded, the download cache goes to /sci-it/scratch/users/$USER/.apptainer_cache. It’s safe to delete; run apptainer cache clean to clear it.
• Don’t point APPTAINER_TMPDIR at /home or /sci-it. Image unpacking creates files with characters (colons) that the shared storage rejects, so pulls will fail. The default (/tmp, node-local) is correct — the module deliberately leaves it alone.
• Building your own containers from a definition file (with --fakeroot) is not enabled on general compute nodes yet. If you need to build a custom container, contact SCI IT — see below.

Need help or a custom container?

If you need a container built from scratch, software that isn’t available as a published image, or you hit an error not covered here, reach out to SCI IT in the #slurm-users Slack channel with the image name or definition file and what you’re trying to run.