From day one, bioAF ran on Google Cloud. That was deliberate: one well-supported reference platform, fully wired together, beats two half-finished ones. But “your data, your infrastructure, your cloud” only really holds if you get to pick the cloud. So in this release we shipped the second one.
bioAF is now platform agnostic. A single setting, cloud_provider, chooses where everything lands: gcp or aws. Pick GCP and you get the same battle-tested path you already know. Pick AWS and bioAF provisions and runs on your own AWS account instead. Nothing about the science layer changes: the same experiments, pipelines, notebooks, and audit trail sit on top of whichever cloud you chose.
One command, now for AWS too
The fastest path is still a single command on your laptop. The Quick Start page now has a cloud-platform selector: choose Google Cloud Platform or Amazon Web Services and the installer command updates to match.
For AWS, that command is:
bash <(curl -fsSL https://raw.githubusercontent.com/bioAF/bioAF/main/install-aws.sh)
install-aws.sh is the sibling of the GCP installer. It checks for (or installs) the AWS CLI v2, verifies your credentials with aws sts get-caller-identity, creates an SSH key pair, a security group, and a scoped bioaf-app IAM role and instance profile, then launches an Ubuntu 22.04 EC2 VM with that profile attached. From there it offers to finish bioAF setup on the VM for you, or prints a worksheet so you can SSH in and run ./bioaf setup yourself.
Just like the GCP path, no long-lived keys ever land on your laptop. The VM authenticates through its attached instance profile, the AWS analog of the GCP VM’s attached service account.
How it stays one platform across two clouds
bioAF talks to its cloud through an internal adapter layer. Compute, storage, notebooks, secrets, IAM, billing, and the rest each sit behind a clean interface, and every backend returns the same backend-neutral model. The control plane never imports a cloud SDK directly, so swapping the cloud underneath it is a matter of selecting different backends, not rewriting the app.
On AWS today, that means S3 for storage and EKS for Kubernetes compute (cluster authentication via IRSA, node autoscaling via the Cluster Autoscaler). GCP remains the complete reference implementation, and because the default is gcp, existing GCP installs are entirely unaffected by this change.
What’s ready, and what’s still landing
We’d rather be honest about the edges than oversell them. On AWS, storage (S3) and Kubernetes compute (EKS) are ready to use now. A few components are still being brought to parity: container image builds, the cellxgene and notebook viewers, and SSH work nodes. If your AWS workflow centers on running pipelines against S3-backed data on EKS, you’re in good shape today. If you depend on one of the components still landing, GCP remains the complete path while we close the gap.
Try it
- New to bioAF? Head to the Quick Start, pick your cloud, and run the one command.
- Already on GCP? Nothing changes. Your install keeps running exactly as before.
- Curious about the details? The prerequisites for both clouds are on the Prerequisites page, and the source is on GitHub.
Same platform. Same data portability promise. Now on the cloud you already use.