The Galaxy bridge
A bridge to a hosted Galaxy bioinformatics server that adds sequencing and genomics tools as an HTTP-async execution class, separate from GPU jobs.
Most of the platform's heavy compute runs as Modal GPU jobs — folding, docking, ADMET. The Galaxy bridge adds a second execution class alongside them: a connection to a hosted Galaxy 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
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 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
jobsrow withbackend: "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). 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.
Was this page helpful?
What you can achieve
Start from the outcome, not the tool. Most goals are served by more than one tool that does roughly the same thing — here's the capability and which tool fits.
The code workspace
Every chat has a private Linux workspace where Ivy writes and runs Python, R, Julia, Octave, notebooks and bioinformatics command-line tools against your files and results.