An agentic analyst for sequencing data: it runs the right pipeline on your own compute, self-heals failures like out-of-memory and missing indexes, verifies the output with real QC checks, and returns a signed, reproducible record. CLI + local dashboard.
No reviews yetBe the first to leave a review for Contig
Maker
📌
Hi Product Hunt 👋
I'm a solo builder with a genetics obsession and an engineering background,
and Contig is my attempt at the unglamorous, unsolved part of bioinformatics.
Turning "find differentially expressed genes" into a workflow is the easy,
crowded part — general LLMs and tools like Galaxy already do it. The hard part
is everything after: actually RUNNING that pipeline on real data, on real
compute, watching it break at hour 3, and fixing it. Frontier models score only
~17% on real bioinformatics analysis (BixBench), and ~74% of wet-lab scientists
don't code at all.
So Contig doesn't just generate a workflow. It:
• runs the pipeline on YOUR compute (Docker locally, or AWS Batch in your account),
• self-heals failures on its own — OOM, a missing index it can rebuild, version
mismatches — and shows you the repair chain (risky fixes pause for approval),
• verifies the output with real QC checks and ends in an honest verdict
(PASS / WARN / FAIL / UNVERIFIED — never a bare "done"),
• and writes a signed, reproducible record you can re-run with one command.
Being honest about maturity, because that's the whole point of the product:
it's Apache-2.0 and free to self-host today. The engine (run → self-heal →
verify → reproduce) is exercised end-to-end on nf-core/rnaseq; six more assays
(scRNA-seq, germline + somatic variants, methylation, 16S, metagenomics) are
wired with QC packs and being hardened to the same bar. The dashboard is
localhost-only for now, and it's pre-revenue.
Try it in 30 seconds (no data of your own needed):
pipx install contig
contig run --run-id smoke # runs, self-heals an injected failure, verifies
contig show smoke # verdict + provenance + repair chain
What I'd love from you: break it, and send me your worst failure cases — every
recovered failure becomes a labeled data point that makes the detector better.
Happy to answer anything here all day.
Report
how does the reproducibility work if my compute or reference versions drift between runs, is the signed record still useful when the underlying environment changes?
Report
Maker
@berrazwqi Great question, and it gets at something we thought hard about. The signature isn't a promise that your environment stays frozen forever, because it can't be. It's a tamper-evident record of exactly what produced a given result: pipeline revision, resolved parameters, container digests, tool versions, input and output checksums, and the reference identity (the FASTA/GTF hash or iGenomes key). The Ed25519 signature just guarantees nobody edited that record after the fact.
So when your compute or reference versions drift, the signed record actually becomes more useful, not less. You rerun, you get a second signed record, and contig diff shows you precisely what changed: which container digest moved, which reference hash differs, and how the QC numbers shifted as a result. Because both records are signed, that comparison is trustworthy. You're not left arguing about whether the old run "really" used version X, it's pinned right there.
The record also tells you honestly whether a run is fully pinned or not, so you know upfront how reproducible it really is rather than finding out later. Short version: we don't prevent drift, we make it visible, attributable, and provable. That's usually the part that's missing.
Report
ran contig on a messy fastq set and the self-heal caught an oom mid-run without me babysitting it, which honestly saved me an evening. love that the output comes back with the actual qc numbers baked in.
Report
Maker
@mcahit321044 Thank you, this is exactly the moment we built Contig for. That OOM catch is the whole thesis in action. The self-heal actually reads the failed task's peak memory from the run's own trace and sizes the retry to fit, instead of blindly doubling and hoping. So it isn't just "retry bigger," it's "retry by this much, because that's what the run told us it needed," and every step gets recorded in the repair chain if you ever want to see what it did while you were away.
And yes, the QC numbers coming back inside the result instead of in some separate report you have to go dig up is very much on purpose. The point is a verified answer, not a pile of logs. Really glad it saved you the evening. If you ever hit a failure it can't self-heal, that's the most valuable thing you could send our way. 🙏
how does the reproducibility work if my compute or reference versions drift between runs, is the signed record still useful when the underlying environment changes?
@berrazwqi Great question, and it gets at something we thought hard about. The signature isn't a promise that your environment stays frozen forever, because it can't be. It's a tamper-evident record of exactly what produced a given result: pipeline revision, resolved parameters, container digests, tool versions, input and output checksums, and the reference identity (the FASTA/GTF hash or iGenomes key). The Ed25519 signature just guarantees nobody edited that record after the fact.
So when your compute or reference versions drift, the signed record actually becomes more useful, not less. You rerun, you get a second signed record, and contig diff shows you precisely what changed: which container digest moved, which reference hash differs, and how the QC numbers shifted as a result. Because both records are signed, that comparison is trustworthy. You're not left arguing about whether the old run "really" used version X, it's pinned right there.
The record also tells you honestly whether a run is fully pinned or not, so you know upfront how reproducible it really is rather than finding out later. Short version: we don't prevent drift, we make it visible, attributable, and provable. That's usually the part that's missing.
ran contig on a messy fastq set and the self-heal caught an oom mid-run without me babysitting it, which honestly saved me an evening. love that the output comes back with the actual qc numbers baked in.
@mcahit321044 Thank you, this is exactly the moment we built Contig for. That OOM catch is the whole thesis in action. The self-heal actually reads the failed task's peak memory from the run's own trace and sizes the retry to fit, instead of blindly doubling and hoping. So it isn't just "retry bigger," it's "retry by this much, because that's what the run told us it needed," and every step gets recorded in the repair chain if you ever want to see what it did while you were away.
And yes, the QC numbers coming back inside the result instead of in some separate report you have to go dig up is very much on purpose. The point is a verified answer, not a pile of logs. Really glad it saved you the evening. If you ever hit a failure it can't self-heal, that's the most valuable thing you could send our way. 🙏