VariantGrid runs one Django codebase four different ways

A Django and PostgreSQL application, not a pipeline

VariantGrid is described in one line as a database and web application for storing, analysing and classifying variants, and the system design section puts the stack at Python 3 with Django and PostgreSQL. That combination makes it an application you run and curate rather than a tool you execute against a file, which is the difference between a one time analysis and a shared resource that accumulates data over years. The repository is the public one, the primary language is Python, the default branch is master, and there are no GitHub releases, so deployments track commits rather than versions, with the last commit pushed on 30 September 2026. The root directory is a Django project in the conventional sense, with manage.py at the top level and a large number of application packages beside it, so anyone expecting a single module will find something closer to a platform.

Five routes in, and none of them is a package install

Installation is offered in three forms and all three point away from the repository. The first is to contact the project, and the maintainers will set up and manage a cloud instance. The second is to install from source or from scratch, with the instructions in the technical wiki. The third is to clone an existing virtual machine, with the wiki page naming AWS, VirtualBox, NECTAR and NCBI instances as the hosts that have been prepared. Documentation is split the same way: a user guide hosted on readthedocs covers using the application, and the technical wiki covers installation and maintenance. Two details suggest the project expects to support several deployments of its own code: a large test_data/ directory at the root, and a sync/ application among the packages, which is the kind of thing you need when more than one instance has to stay consistent.

Free for research, licensed for production, open in four years

The licensing section is the part of this README most likely to affect a decision. The code is free to use for research and evaluation, while production commercial use requires a licence, and the sentence that follows sets a deadline: before the code becomes fully free and open source in four years. The detail sits in LICENCE.md at the repository root, and the README asks readers to contact the project to discuss support or collaboration. So the project runs on a two tier model where evaluation is open, production is commercial, and openness is scheduled rather than granted. One inconsistency is worth noticing while you read it: the Node manifest at the root declares the package licence as ISC, which is a permissive string that does not describe the arrangement above. For a Python application the manifest is incidental, but it is the kind of detail that ends up in a procurement questionnaire answered from the wrong file.

VCFs in, Ensembl VEP annotation out

The analysis and curation section describes what happens once data is uploaded, and the list is specific. VCFs are annotated automatically with Ensembl VEP. From there, the application can show you every sample from every uploaded VCF that shares a given variant, which is the capability that makes a shared instance worth building. Samples, trios or cohorts can be analysed and filtered through real time drag and drop interactive analyses rather than a form. Variants are classified with a customisable ACMG form, so the criteria your lab uses can be encoded rather than typed into free text notes. Reference builds are handled inside the same database, covering GRCh37, also known as hg19, GRCh38, Ensembl and RefSeq, with some conversion done automatically rather than requiring you to normalise upstream. Data management and curation are in scope too, including patient phenotypes.

One codebase, four deployment shapes

The use case list is really a list of operating models, and the named instances show all four working. Public servers start with VariantGrid.com, a research focused instance with free user access, which is where a new user should look before installing anything. Collaborative data sharing sites run the same code for a network rather than for individuals, with Shariant Australia as an Australian Genomics variant interpretation sharing server and RUNX1Db as a rare blood disease data sharing site. Private servers are the third shape, where SA Pathology uses it for clinical and diagnostic work as the South Australian public pathology service, and where labs at the Centre for Cancer Biology keep research exomes. Those four shapes have different requirements on curation effort, access control and uptime, which is why the licensing terms differ by use as well as by audience.

Forty applications and a hash pinned dependency file

The root listing is the fastest way to understand the scope. Alongside the core packages sit analysis/, annotation/, classification/, genes/, expression/, review/, upload/, patients/, pedigree/ and library/, and then domain specific ones such as snpdb/, variantopedia/, mme/, beacon/, seqauto/, oidc_auth/, vcauth/ and ontology/. There is a paper/ package, an email_manager/, an eventlog/, a user_messages/ package, a scripts/ directory and a manual/ directory, so features that would be plugins in a smaller application are first class apps here. Dependencies are handled with uv rather than a hand written list: requirements.txt was autogenerated by uv pip compile requirements.in --generate-hashes -o requirements.txt --python-version 3.12, with entries such as aiohttp==3.14.3 and aiohappyeyeballs==2.7.1 pinned together with their hashes. An environment.yml sits alongside it for conda users, and the tooling files are modern, with ruff.toml, mypy.ini and an .importlinter contract file.

An ESLint config and a failing test script in a Python repo

The last oddity is the Node side. A package.json at the root defines the package as variantgrid version 1.0.0 with the same description as the project, and its test script is the npm placeholder that prints an error and exits with status 1, because no JavaScript test is specified. Its only development dependencies are eslint and globals, matching an eslint.config.mjs that also sits at the root, so something in the repository is linted by ESLint even though the application is Python. The package declares ISC as its licence and its author field is empty. Alongside that there are development configuration folders for editors, including .idea/, .project and .pydevproject, an AGENTS.md file, and two directories named .claude/ and claude/, which together suggest that agent instructions and generated artefacts have become part of the repository layout rather than living outside it.

Editorial conclusion

VariantGrid fits a genomics group that already has VCFs and wants one database where samples sharing a variant are visible across uploads, annotation happens automatically through Ensembl VEP, and classification is recorded against a customisable ACMG form. It is the wrong tool for anyone who needs an unrestricted licence today, because commercial production use requires a separate licence and the code is only promised to become fully open in four years, and it is also wrong for anyone expecting a one command install, since the three supported routes all involve the project or its wiki. Before you start, decide which of the four deployment shapes you are building, contact the maintainers about support or collaboration, read LICENCE.md rather than the ISC string in the Node manifest, and pin dependencies with the same uv compile command the project uses if you install from source.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases