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.
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, measured ~2.5× cheaper per core 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
123 packages — native arm64, verified, signed, public
The fieldwork CPU-prep stack. Headline packages:
earth-observation
236 packages — native arm64, verified, signed, public
The geospatial base plus the labeled-array / lazy / STAC layer:
geo-ml
378 packages — CPU machine learning on geospatial / tabular data
climate
247 packages — atmospheric / climate analysis (GRIB + regridding)
pointcloud
287 packages — LiDAR / DEM / terrain processing
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.