Skip to contents


SigRepo_Server

SigRepo_Server is the server half of SigRepo, a platform for storing, sharing, and comparing omic signatures. It is a reproducible framework for deploying a SigRepo instance — locally or on a Linux-based cloud host — and for interacting with it through a REST API, an R Shiny web interface, and an MCP server for AI agents.

The client half is the SigRepo R package; signatures themselves are represented as R6 objects defined by OmicSignature, our in-house package.

Architecture

The server is a set of containerized services:

  • MySQL database — initializes and manages the SigRepo schema, storing signatures, collections, users, controlled vocabularies (organisms, platforms, sample types, assay types), and gene set resources. Per-signature differential-expression (difexp) tables are held in a companion object store.
  • Plumber REST API — the single access path to the data. It defines the schema, loads reference tables, stores and retrieves difexp objects, authenticates every call by api_key, and exposes the analysis endpoints (signature comparison, enrichment) so that analysis runs server-side rather than requiring users to download whole signatures.
  • Web interface — an R Shiny application (legacy_app/), run by Shiny Server, and the interface our instance serves. From the browser you sign in, browse and deposit signatures and collections, browse the controlled vocabularies and gene set resources, and compare signatures. Two properties decided it over the React app it replaced: it bind-mounts its source, so a UI change ships with a git pull and a container restart rather than an image build; and Shiny Server gives every user their own R process, so an analysis runs in that user’s session instead of queueing behind everyone else in the single-process API. The React single-page app is still in the repo under web/ and still builds as the sigrepo-web container, but it is no longer the served interface.
  • MCP server — a Model Context Protocol endpoint that lets AI agents search signatures, retrieve signature context, compare signatures, browse gene sets, and run enrichment, grounded in the stored data. It sits behind a rate-limiting reverse proxy and is reachable at https://sigrepo.org/mcp/.

Because analyses are exposed as discrete API endpoints over a common signature representation, additional analysis engines and external gene-set resources can be added as new endpoints without changing the database schema.

Our deployed instance

Our team runs a SigRepo server on DigitalOcean.

Analysis endpoints

Beyond storage and retrieval, the API supports analysis over stored signatures:

  • Signature comparison — any set of signatures can be compared by feature overlap (Jaccard index with Fisher exact tests), by rank-based Kolmogorov–Smirnov statistics, or by GSEA, returning similarity matrices and, for GSEA, per-pair leading-edge data. Bi-directional signatures are compared per matched group label.
  • Gene set enrichment — over-representation and rank-based enrichment against MSigDB via hypeR, with MSigDB collections cached server-side.

In development

Active work, not yet part of the deployed stack:

  • Signature enrichment in the web interface — the Shiny Annotate tab is being rebuilt directly on hypeR, so that the tab and the SigRepo R package run enrichment the same way. The tab shows an under-development page until that rebuild lands; the API’s enrichment endpoints are unaffected.
  • AI-assisted signature authoring — an agent service that reads a study’s differential-expression output and description, proposes metadata from SigRepo’s controlled vocabularies, and emits a validated OmicSignature for the depositor to review, so contributing a signature becomes a review step rather than a curation task.
  • Additional external gene-set resources for matching stored signatures against published gene sets.

Deployment

See the installation guide for standing up your own instance. install_sigrepo.sh starts the database and the API, builds the schema and reference tables, and brings up the Shiny interface. The stack is defined with docker compose; the MySQL service, the API, the Shiny interface, and the MCP server each run as their own container on a shared internal network, with only the intended ports published.