Deploy Open Targets Platform Locally: Full Setup Guide

Here’s the mistake almost everyone makes: they Google “Open Targets install”, land on the platform-app or webapp GitHub repos, run yarn install, and wonder why nothing works. Those repos live under opentargets-archive. They’re dead. The frontend by itself is useless without ClickHouse, OpenSearch, and the GraphQL API behind it.

What you actually want for drug target discovery on your own hardware is the platform-deployment-standalone tool. It wraps Docker Compose, Terraform, and a Go configurator into a single ./platform binary that can spin up a full local replica of any Open Targets release from 24.03 onward – earlier releases can’t be reproduced with it, which catches people who assume any historical version is available. This guide walks through deploying the latest release (26.06 as of mid-2026 – check the release notes before you start, since the platform ships quarterly).

Why self-host at all?

The public instance at platform.opentargets.org is free and always current. Ninety percent of users never need more. You self-host when one of three things is true: you’re working with sensitive internal target lists you don’t want hitting an external API, you need to pin a specific release for reproducibility in a paper, or you’re planning to inject proprietary evidence sources into the associations scoring.

The last case is the killer feature. The Platform’s whole value is that it fuses ChEMBL, GWAS Catalog, Reactome, ClinVar, and a dozen other sources into one target-disease score. Adding your company’s internal RNA-seq screens into that pipeline – that requires local infrastructure.

System requirements for the standalone deployment

Per the official README, these are the numbers to plan around:

The ~300GB figure (as of 25.12) catches people off guard on laptops. Half of it is the raw ClickHouse and OpenSearch disk images; the rest is the tarballs those are unpacked from. You can reclaim about 118GB post-install by wiping the downloads folder – more on that later.

Download and prep the tool

Clone the repository and build the Go binary. There’s no pre-built release – you compile ./platform yourself with make.

# Install prerequisites (Ubuntu example)
sudo apt update
sudo apt install -y golang docker.io docker-compose-plugin pigz make git
sudo usermod -aG docker $USER # log out and back in after this

# Clone and build
git clone https://github.com/opentargets/platform-deployment-standalone.git
cd platform-deployment-standalone
make

# Verify the binary
./platform --help

If make exits with a Go version complaint, you probably have the distro’s ancient Go package. Grab a current one from go.dev instead – the toolchain is picky about modules.

Deploy release 26.06 locally

The tool is command-driven with three verbs that matter: deploy, destroy, list. For a local install:

1. Pick your target release from the release notes (e.g. 26.06).
2. Set the profile: make set_profile profile='26.06'
3. Set the required secret – even if you don’t want AI features:

   # The openai_token is technically optional but the deploy WILL fail without it.
   # Set to an empty string to disable literature summarisation.
   echo -n "" > secrets/openai_token

4. Bring it up: ./platform deploy (or make platform_up on older tags)

The tool pulls compressed disk images, decompresses them with pigz, and mounts them into ClickHouse and OpenSearch containers. Docker Compose then starts the GraphQL API, the AI API sidecar, and the nginx frontend. How long that takes depends heavily on your connection speed and disk throughput – community reports range from under 30 minutes on fast NVMe to several hours on spinning rust.

Pro tip: Don’t set openai_token to a real key on a local instance you’re going to share screenshots of. The literature summarisation feature makes live OpenAI calls whenever anyone opens an evidence page – that bill compounds fast if a team hits it. Empty string is the safe default for internal deployments.

Verify it’s actually working

Three checks, in order of usefulness:

# 1. Are the containers alive and (crucially) healthy?
docker ps --format 'table {{.Names}}t{{.Status}}'
# Look for ot-clickhouse, ot-es, ot-api, ot-openai-api, ot-webapp
# ALL should show (healthy), not just "Up"

# 2. Does the GraphQL API respond?
curl -s http://localhost:8080/api/v4/graphql 
 -H 'Content-Type: application/json' 
 -d '{"query":"{ meta { name apiVersion { x y z } } }"}'

# 3. Open the web UI
xdg-open http://localhost:8080

Start with the GraphQL meta query – if it returns a version JSON, the API is alive and the data volumes mounted correctly. The web UI can look fine while the API is still warming up, so don’t trust the browser alone.

Which raises a question worth sitting with before you hit the errors section: what do you actually do once the stack is running? If the answer is “run the same queries I’d run on the public portal,” you probably don’t need local infra. The deployment effort pays off when you’re scripting batch lookups against a pinned release, integrating with an internal pipeline, or experimenting with custom evidence injection. Keep that use case in mind – it shapes which errors matter and which you can safely ignore.

The three errors that actually bite people

ot-es container unhealthy on Ubuntu 24.04

Multiple community reports (forum thread, GitHub issue #3826) describe the ot-es container looping through java.nio.file.NoSuchFileException errors on Ubuntu 24.04.01, even after upstream patches. The pragmatic fix: deploy on Ubuntu 22.04 LTS instead. The team has tested against it, and the container starts cleanly. Not glamorous, but it’s the shortest path to a working stack.

Deploy fails immediately with a Terraform backend error

The tool reads etc/default.tfbackend even for local deployments. If the bucket and prefix values point to a GCS bucket you don’t own, Terraform refuses to initialise. Edit that file first and point it at any bucket you control – or, for pure-local runs, leave it as-is only if the profile you selected doesn’t need remote state. Cloud deploys always need this.

Out-of-memory during OpenSearch startup

16GB is the floor, not a comfortable spec. If ot-es keeps OOM-killing on a 16GB machine, either close every other process on the host or bump Docker Desktop’s memory allocation to 12GB minimum. On Linux servers there’s no separate allocation – the container gets whatever the kernel lets it have.

Upgrade and cleanup

Upgrading is not an in-place operation. The release model treats each version as an immutable data image. To move from 26.03 to 26.06:

# Tear down the old deployment
./platform destroy # or: make platform_down

# Switch profiles
make set_profile profile='26.06'

# Deploy again
./platform deploy

Your previous ClickHouse and OpenSearch volumes are gone the moment destroy runs. Any custom evidence you injected via a modified ETL run needs to be reapplied from scratch on the new release – there is no migration script, and the team hasn’t signalled one is coming.

For a full uninstall, run ./platform destroy, then delete the cloned directory and prune Docker: docker system prune -a --volumes. To reclaim the extra ~118GB the README notes, delete the downloads/ folder inside the repo before pruning – those tarballs are only needed during initial extraction.

FAQ

Can I deploy Open Targets Genetics separately?

No standalone Genetics deployment tool exists – community members have asked, and there’s no repository for it. Since the 25.03 release, Genetics is part of the main Platform. Deploy the Platform and use its variant/study/credible-set entities.

Do I need Google Cloud for a local install?

Not for the local path itself – Docker is enough. GCloud CLI and Terraform only come into play if you use ./platform deploy against a cloud target. However, one quirk: the release data itself is hosted on Google Cloud Storage and EMBL-EBI’s FTP, so a functioning internet connection is required during the initial image pull. Air-gapped installs work only if you pre-stage the tarballs on the target machine.

How current will my local instance be?

Whatever release you pinned. That’s the point – a 26.06 local deploy in mid-2027 still shows 26.06 data. Frozen, reproducible, cite-able in a paper. If you want live data with quarterly updates, use platform.opentargets.org or one of the cloud mirrors: AWS Open Data (available since 26.03) or Azure Open Datasets (available since 24.09), roughly 350GB refreshed per release cycle.

Next step: Run ./platform deploy on a 22.04 box with 20GB of RAM to spare, then open http://localhost:8080, search for your favourite target gene, and confirm the associations page loads. If it does, you’re ready to start swapping in custom evidence.