How GENI Workflows is organised

Cloud platforms have become the default place to process large volumes of genetic data. Diagnostic laboratories and research projects use AWS and GCP both to store genomic data and to run bioinformatics pipelines. To stay efficient, processing tasks — alignment, variant calling, annotation — are orchestrated by systems such as Nextflow and Cromwell.

Deploying those systems on cloud infrastructure yourself is complex. Using a managed service such as Amazon HealthOmics removes that work but is expensive.

GENI Workflows sits between the two. It aims to reduce cloud spend, simplify the management of compute resources, centralise bioinformatics operations, and give you visibility and control over what you are spending.

The user controls cloud and bioinformatics resources through one API. GENI holds the data — users, workflows, submissions, metrics, costs — and delegates pipeline execution to the tenant’s own AWS accounts and GCP projects.

The split

The architecture manages resources through an authenticated API, while the pipelines themselves execute in the customer’s cloud accounts. Two consequences follow, and they are the reason the product is shaped this way:

• Administrators keep control. Every cloud resource GENI provisions lives in an account you own. Your sequencing data never leaves it.
• Analysts get one interface. One CLI and one API cover every account, every region and both clouds. You develop a pipeline in a dev account and process real samples in a prod account without changing anything but an identifier.

What to read next

• Cloud resources — Environment, Engine, Queue, Storage, Registry, Plugins.
• Bioinformatics resources — Workflow, Submission, Task, Instance, Tags.
• User roles — what an analyst may do, and what requires an administrator.