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:
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.