Native arm64 bioinformatics
containers, no emulation.
The bioconda packages already work on arm64. The containers haven't caught up. aarchbio rebuilds BioContainers natively for Apple Silicon and AWS Graviton — signed, public, no account required.
A gap, not a failing
aarchbio stands on the shoulders of bioconda, BioContainers, nf-core, and Seqera/Wave — an enormous, mostly-volunteer good. arm64 simply hasn't finished catching up.
The machines researchers use are increasingly arm64 — every
Apple Silicon Mac, every AWS Graviton instance. But the ~10,000 BioContainers
images are still essentially all linux/amd64.
On a Mac, Docker quietly emulates the amd64 image under QEMU — slower,
occasionally subtly wrong, with no signal anything is off. On a vanilla
Graviton instance there's no emulation layer, so the same image fails to
start at all: exec format error.
We surveyed the gap rather than guessing. About a third of bioconda packages are noarch (Python/Java — architecture-neutral by nature) and another third ship native linux-aarch64 builds. Only ~8% are genuinely arm64-blocked. Yet across five popular nf-core pipelines, every container they pull is amd64-only — about a third of them Seqera Wave "mulled" images, a clever approach whose arm64 builds just aren't there yet. The packages are ready; the container publishing is what hasn't caught up. That's the one gap aarchbio fills — and ideally helps close upstream.
Scope, deliberately narrow: aarchbio rebuilds
bioinformatics tool containers (the BioContainers / bioconda layer) —
nothing else. Distro base images (ubuntu), framework packages
(tensorflow, via conda-forge), and vendor ML containers already
handle arm64 and aren't ours to rebuild. When a tool can't be built, the cause
usually lives in one of those layers — surfaced in
GAPS.md
and fixed upstream, where it belongs. We don't compile from source — that would
make us a second bioconda and break the verifiable-build trust model.
How it works
A BioContainers image is essentially conda install <pkg> in a base container. Rebuilding for arm64 is the same recipe, native.
No emulation, ever
Each architecture builds on its own native runner — arm64 on arm64, amd64 on amd64 — then merges into one manifest. We never emulate to publish images whose whole purpose is ending emulation.
noarch served everywhere
Python/Java tools are architecture-neutral, so they're published as multi-arch manifests (amd64 + arm64). Docker picks the native one on any host — Mac or Graviton.
Signed, traceable
Every image is cosign keyless-signed in CI and logged to the Sigstore transparency log. Anyone can verify it was built by our public workflow, from a specific commit — no need to trust us.
Fused tools, handled
Wave-style "mulled" images that fuse several tools into one container are rebuilt native too — the multi-package case is first-class, not an afterthought.
Use it
Point your pipeline's registry at aarchbio. The same config works on an Apple Silicon laptop and a Graviton server — Docker selects the arm64 image automatically.
500+
tools published — native arm64, signed, public
Covering the large majority of the nf-core ecosystem. A representative sample:
Looking for a package? Which project
aarchbio has a sister project, aarchsci. The split is the shape of what you get — one tool, or a whole environment — not which field of science it belongs to.
You want one tool, pinned to a version. That is here. Every image is a single package tagged <version>--<build> to mirror a BioContainers reference, so it drops straight into a pipeline or a registry override: quay.io/aarchbio/samtools:1.22.1--h96c455f_0.
You want a working environment for a field. That is aarchsci — many packages solved together and ready to run: single-cell, neuroimaging, geospatial, md, comp-chem.
The two overlap on purpose. scanpy is a single-tool image here and a component of aarchsci’s single-cell environment — different artifacts for different jobs, and both should exist.
One clarification, because older wording here implied otherwise: bioconda is where these packages usually come from, not what defines the scope. Where bioconda has no recipe, or one frozen years behind a package that has moved to conda-forge, aarchbio builds from conda-forge instead and records the real source in the image’s io.aarchbio.source-channel label. The rule is whichever channel actually provides a working package — a faithful rebuild of something that cannot even import is useful to nobody.
Verify, don't trust
The whole point is that you don't have to take our word for it.
Images are built by a public GitHub Actions workflow, keyless-signed with Sigstore, and recorded in the Rekor transparency log. The signature attests which workflow, which repo, which commit produced the image. The build is reproducible — re-run it yourself and get the same result. Trust the process, not the publisher.