---
title: The Galaxy bridge
description: >-
  A bridge to a hosted Galaxy bioinformatics server that adds sequencing and
  genomics tools as an HTTP-async execution class, separate from GPU jobs.
tags:
  - concepts
  - galaxy
  - bioinformatics
  - tools
---

Most of the platform's heavy compute runs as [Modal GPU jobs](/docs/how-orchestration-works) — folding, docking, ADMET. The Galaxy bridge adds a second execution class alongside them: a connection to a hosted [Galaxy](https://galaxyproject.org) bioinformatics server that contributes a large catalog of sequencing and genomics tools the platform does not run itself. When you ask about FASTQ quality, genome assembly, variant calling, RNA-seq differential expression, or microbiome profiling, the orchestrator reaches across this bridge instead of dispatching a Modal job. This page explains what the bridge is, how its tools execute, and when the orchestrator picks a Galaxy tool over a Modal one.

> **Availability**

> Galaxy tools appear only when the bridge is enabled (`FEATURE_GALAXY_BRIDGE`) and at least one Galaxy server API key is configured (`GALAXY_API_KEY` or `GALAXY_EU_API_KEY`). If the bridge is off, these tools are hidden from the orchestrator, and a call that still names one returns guidance toward a Modal-hosted alternative instead of failing silently.

## Citations

> The Galaxy Community. The Galaxy platform for accessible, reproducible, and collaborative data analyses: 2024 update. *Nucleic Acids Research*. 2024;52(W1):W83-W94. doi: [10.1093/nar/gkae410](https://doi.org/10.1093/nar/gkae410)

## A second execution class

The platform runs tools in more than one way. A Modal tool spins up a serverless GPU container and writes its result to a `jobs` record. A [sandbox](/docs/sandbox) tool runs code in a per-chat container. Galaxy tools are a third, distinct class: **HTTP-async**.

When the orchestrator calls a Galaxy tool, the request is intercepted by a dedicated execution stage that proxies it to the Galaxy server over HTTP, receives a Galaxy job handle back, and then polls the Galaxy server for completion. Two consequences follow from this being HTTP-async rather than a Modal job:

- **The work runs on the Galaxy server, not on the platform's GPU fleet.** Almost every Galaxy tool is CPU-bound (a rare exception, like the DeepVariant caller, requests GPU on the Galaxy side). Long-running assemblies and alignments happen remotely and are polled, not held open.
- **Progress comes from the Galaxy server's own job state.** On submit, the bridge records a platform `jobs` row with `backend: "galaxy"` and the Galaxy job and history ids, then polls Galaxy and copies its status onto that row. The output renders as a canvas card, so from your side a Galaxy tool looks and behaves like any other job in a chain.

## The `galaxy_` prefix and siloing

Every Galaxy tool name is prefixed `galaxy_` — `galaxy_fastqc`, `galaxy_spades_assemble`, `galaxy_deepvariant_call`, and so on. The prefix is not cosmetic: it is how the bridge silos this class of tools so it can never collide with a native Modal backend.

At load time the bridge's tool names are checked against the platform's registry of confirmed Modal job types (`KNOWN_JOB_TYPES`). If any `galaxy_` name overlapped a real Modal backend, the module throws and refuses to load — a Galaxy tool is never allowed to shadow a tool the platform already runs natively. Membership in the Galaxy registry is also what the proxy stage keys on: a tool call is routed across the bridge only if its name is in that set, otherwise it passes straight through to the normal Modal and sandbox stages.

## The domains it covers

The bridge contributes several dozen tools across the bioinformatics domains below — sequencing and genomics workflows the platform does not otherwise host. The tools are designed to chain: a QC tool feeds a trimmer, which feeds an aligner, which feeds a variant caller or a counter, which feeds an annotator or a differential-expression test. The table below groups them by domain with representative tools; the bridge registry (`src/lib/orchestrator/tools/galaxy/definitions/`) is the source of truth for the exact set.

| Domain | Representative tools | Typical use |
|---|---|---|
| QC / preprocessing | `galaxy_fastqc`, `galaxy_fastp_trim`, `galaxy_trimmomatic`, `galaxy_multiqc` | Assess raw FASTQ, trim adapters, aggregate QC |
| Genome assembly | `galaxy_spades_assemble`, `galaxy_flye_assemble`, `galaxy_megahit_assemble`, `galaxy_quast_assess` | De novo assembly from short, long, or metagenomic reads |
| Genome annotation | `galaxy_prokka_annotate`, `galaxy_busco_assess`, `galaxy_augustus_predict` | Annotate genes and assess assembly completeness |
| Phylogenetics | `galaxy_mafft_align`, `galaxy_iqtree_build`, `galaxy_raxml_build`, `galaxy_fasttree_build` | Multiple alignment and tree building |
| Nanopore / long-read | `galaxy_nanoplot_qc`, `galaxy_porechop_trim`, `galaxy_medaka_consensus` | QC, trim, and polish Oxford Nanopore data |
| 16S / amplicon | `galaxy_dada2_denoise`, `galaxy_qiime2_diversity`, `galaxy_mothur_classify` | Amplicon denoising, diversity, taxonomy |
| Metagenomics | `galaxy_kraken2_classify`, `galaxy_metaphlan_profile` | Shotgun taxonomic classification and community profiling |
| Variant calling & annotation | `galaxy_deepvariant_call`, `galaxy_freebayes_call`, `galaxy_bwa_mem_align`, `galaxy_vep_annotate`, `galaxy_snpeff_annotate` | Align reads, call SNPs/indels, annotate effects; somatic and structural variant callers extend this |
| RNA-seq | `galaxy_star_align`, `galaxy_salmon_quant`, `galaxy_featurecounts_count`, `galaxy_deseq2_de` | Align or pseudo-align, count, and test differential expression |
| Epigenomics | `galaxy_hicexplorer_build`, `galaxy_macs2_callpeaks`, `galaxy_bismark_align`, deepTools utilities | Chromatin architecture, peak and methylation workflows |
| GWAS | `galaxy_plink_assoc`, `galaxy_gemma_gwas`, `galaxy_prsice_calculate` | Genome-wide association and polygenic scoring |
| Metabolomics | `galaxy_xcms_process` | Untargeted LC-MS feature processing |
| Extended single-cell & specialty RNA | single-cell, small RNA, spatial, and non-coding RNA tools | Downstream single-cell and specialty transcriptomics |

Workflow-glue utilities (BAM, VCF, and BED operations such as `galaxy_samtools_stats` and `galaxy_bedtools_intersect`) sit under these domains as the connective tissue between alignment, counting, and calling steps.

## When the orchestrator reaches for a Galaxy tool

You do not choose Galaxy versus Modal — the orchestrator routes on the capability your request implies, the same way it does for any tool ([how it decides](/docs/how-orchestration-works)). In practice it reaches across the bridge when your goal is a **sequencing or genomics workflow keyed on read data or genomic files**: raw FASTQ that needs quality control, reads to assemble into a genome, a BAM to call variants from, an RNA-seq experiment to test for differential expression, or amplicon data to profile a microbiome.

By contrast, the platform's own Modal tools serve the drug-discovery capabilities the bridge deliberately does not duplicate — protein folding, molecular docking, ADMET, and synthesis planning. Because the two catalogs are kept non-overlapping by the siloing rule above, a given capability resolves cleanly to one class or the other, and the orchestrator can chain a Galaxy step and a Modal step in the same request when a goal spans both.

> **When the bridge is unavailable**

> If a deployment has the Galaxy bridge switched off, a request that would need a `galaxy_` tool does not stall. The proxy stage returns a clear message naming a Modal-hosted alternative — for example, pointing a metagenomics request at the platform's own classification and profiling tools — so Ivy can pivot rather than retry a tool that cannot run.