Native arm64 scientific
containers, verified to work.
The conda-forge geo stack — GDAL, PROJ, GEOS, rasterio, shapely,
scikit-image — won't pip install on arm64
(No matching distribution found for rasterio). It solves
clean on conda-forge.
aarch.science builds it native for Apple Silicon and AWS Graviton —
and proves each image imports and runs, not just solves.
Looking for a specific tool?
| aarch.bio | aarch.science | |
|---|---|---|
| unit | one tool per image (~503) | a curated multi-package env (29) |
| example | samtools, bwa, bcftools |
geospatial, dft, astro, single-cell |
| source | bioconda / BioContainers | conda-forge |
| you want it when | "I need this tool for a pipeline step" | "I need a working stack to import against" |
A delivery gap, one layer over
aarch.science stands on conda-forge — an enormous, mostly-volunteer good. The arm64 packages are already there. The way most people reach for them isn't.
The machines doing science are increasingly arm64 — every Apple Silicon Mac, every AWS Graviton instance. We measured the geo-prep stack at 1.87× better price/performance on Graviton c7g vs Intel c7i (1.52× faster, 1.23× cheaper) — for CPU-bound geospatial work.
But the native-library scientific stack — GDAL, PROJ, GEOS and the Python
packages on top of them (rasterio, fiona, shapely, pyproj) — has incomplete,
Python-version-fragile arm64 wheel coverage on PyPI. Reach for it with
pip on a Graviton box and you get
No matching distribution found for rasterio. The build falls
back to expensive Intel, leaving the price/perf win on the table.
The packages do exist on arm64 — conda-forge ships
linux-aarch64 builds, and the whole geo stack solves cleanly there
(123 packages, all native). The gap isn't porting; it's that there's no
curated, verified set of containers built from those packages.
That's what aarch.science fills.
The subtle part — and why "verified" is the whole point:
an environment can solve and still fail to assemble on arm64
— a missing native lib, an ABI mismatch, a broken wheel. pip "solved" too, then
import rasterio would have failed. So every aarch.science image is
tested inside the built arm64 container: it must import every headline
package and do real work — reproject a point through PROJ, run GEOS
geometry ops, write a GeoTIFF and read it back through both rasterio and raw
GDAL. Only then does it earn the tag.
How it works
A curated conda-forge environment, built native per architecture, then proven to run before it's published.
No emulation, ever
Native-library envs build on a native arm64 runner — no QEMU. We never emulate to publish images whose whole purpose is running native on Graviton and Apple Silicon.
Whole stacks, not loose packages
conda-forge ships packages, not containers. We curate version-pinned environments by workflow — geospatial first — committed as the source of truth and versioned by content hash.
Solve ≠ run
The build refuses to tag unless the env imports every headline package and passes a functional smoke test inside the arm64 image. The smoke test is baked in, so you can re-run it on what you pull.
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.
Use it
Pull the verified geospatial image and run native. The same image works on an Apple Silicon laptop and a Graviton server.
geospatial
110 packages — native arm64, verified, signed, public
The fieldwork CPU-prep stack. Headline packages:
earth-observation
246 packages — native arm64, verified, signed, public
The geospatial base plus the labeled-array / lazy / STAC layer:
geo-ml
368 packages — CPU machine learning on geospatial / tabular data
climate
267 packages — atmospheric / climate analysis (GRIB + regridding) + ocean thermodynamics
pointcloud
234 packages — LiDAR / DEM / terrain processing
comp-chem
212 packages — cheminformatics, molecular dynamics, quantum chemistry & docking
dft
236 packages — plane-wave & LCAO density-functional theory, MPI-parallel
md
246 packages — classical molecular dynamics, MPI-parallel
viz
246 packages — headless scientific visualisation, rendered on CPU
r
328 packages — R for scientific work, the catalog's first non-Python env
astro
361 packages — the Astropy ecosystem, for astronomy and astrophysics, plus N-body dynamics
fem-cfd
131 packages — FEniCSx + CalculiX: finite-element PDE solving and structural FEA, MPI-parallel
cfd-fv
56 packages — SU2: finite-volume CFD (compressible / aerodynamic), MPI-parallel
optimization
64 packages — LP & mixed-integer programming (operations research)
neuroimaging
296 packages — volume-based fMRI, diffusion & structural MRI
single-cell
532 packages — single-cell transcriptomics, both ecosystems in one image
bayes
125 packages — Bayesian inference & MCMC with Stan
geoscience
113 packages — seismology & groundwater flow (solid earth / subsurface)
cp2k
111 packages — CP2K: Gaussian + plane-wave DFT and ab-initio MD, MPI-parallel
pathology
209 packages — digital pathology / whole-slide imaging
quantum
165 packages — quantum circuit simulation
hep
355 packages — high-energy physics
pic
167 packages — particle-in-cell plasma physics
structbio
121 packages — crystallography & structural biology
popgen
247 packages — coalescent simulation / population genetics
tomography
88 packages — CT reconstruction
psi4
82 packages — molecular quantum chemistry
nlp
91 packages — natural-language processing
gw
216 packages — gravitational-wave astronomy
Verify, don't trust
Two independent things you can check yourself: that it works, and where it came from.
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. And because the smoke test is baked in, you can confirm the env imports and runs on your own hardware. Trust the process, not the publisher.