OpenDota Core: Running the Dota 2 Replay Parsing Platform

OpenDota Core's data pipeline and intended operators

OpenDota Core addresses a specific problem: turning Dota 2 match information from Valve's WebAPI and replay files into API responses for clients such as the OpenDota UI. The repository describes two input paths. Basic match and player profile data comes from the Steam WebAPI, while richer match data can come from fully automated parsing of `.dem` replay files. The resulting platform is therefore more than an Express endpoint around an upstream Dota service. It also coordinates retrieval, archive storage, parsing, persistence, caching, and response generation.

The intended users are backend developers who want to inspect or host the OpenDota API, contributors working on the parsing stack, and organizations that need access to the platform's code rather than depending only on its public deployment. The OpenDota UI is identified as a consumer of this API, which gives the repository a concrete reference workload rather than leaving the backend detached from a known frontend.

The README does not position Core as a general-purpose game analytics package or a client for replay files. Its scope is the OpenDota service itself. That distinction matters because adopting the repository also means accepting its database layout, service boundaries, Steam retrieval assumptions, and Java parser integration. A developer who only needs one match summary may find those dependencies excessive, while a developer building a comparable Dota data service may find the service definitions and persistence layer relevant.

Microservices, storage engines, and replay parsing

The architecture is split into Node.js microservices managed by `pm2`. Each service runs as a separate Node.js process. By default, only the web service is launched, which means starting the core container does not automatically enable every part of the replay pipeline. The README names additional services such as `retriever`, `parser`, and `gcdata`, and the package scripts include a separate `fullhistory` service.

The stack combines PostgreSQL, Redis, Cassandra, and MinIO. The Compose configuration connects the core service to PostgreSQL at `postgresql://postgres:postgres@odota-postgres/yasp`, Redis at `redis://odota-redis:6379/0`, Cassandra at `cassandra://odota-cassandra/yasp`, and MinIO through `http://odota-minio:9000`. These settings are environment variables passed to the container, not hard-coded application constants in the example. The database choices suggest different operational roles, although the repository files do not document a complete storage schema or the exact query path for every API endpoint.

Replay parsing adds a second runtime. The parser image is `odota/parser`, and the application is told to reach it through `PARSER_HOST: odota-parser:5600`. The README identifies Java and clarity as the parser technology. This makes Core unsuitable for a one-process deployment if replay parsing is a core requirement. It also creates a maintenance boundary between the TypeScript application and a separately supplied parser image. If that image changes, the README specifically documents pulling `odota/parser` and recreating the parser container.

Docker installation and the first API request

The documented quickstart uses Docker and Docker Compose. Create the local configuration file first. The README says that `config.js` contains the full option list, although the repository entry is named `config.ts`, so operators should account for that difference when looking for settings. The Steam API key is required for Steam WebAPI access. Replay parsing additionally requires Steam account credentials, and the README recommends an alternate account because the account cannot log in through another Steam client at the same time and must not have Steam Guard enabled.

The documented installation sequence is:

curl -sSL https://get.docker.com/ | sh
curl -L "https://github.com/docker/compose/releases/download/1.17.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose
cp .env_example .env
docker-compose up

The first command installs Docker. The second installs the Compose binary at `/usr/local/bin/docker-compose`. The third copies the example environment file, and the last command starts the containers and initializes the databases as described by the README. The Compose file exposes ports 5000 and 5100. The README says the API runs on port 5000 by default, so a local request can target that port once the containers are running.

For a first documented parse request, start the services required by the README:

pm2 start ecosystem.config.js --only web,retriever,parser,gcdata
npm run request

The `npm run request` script expands to a POST request for match ID `7490235544`. The README says this is an example request for parsed match data, not a documented response shape. For a player's match history refresh, the documented commands are:

pm2 start ecosystem.config.js --only fullhistory
npm run fullhistory

The `npm run fullhistory` script sends a POST request to `/api/players/88367253/refresh`, and the README describes it as a request for up to 500 recent matches. These commands are starter operations, not a complete production setup guide.

Service startup, inspection, and database operations

OpenDota Core keeps routine process management behind `pm2`, which is useful when the deployment needs more than the default web process. The README documents listing running services, starting all services, starting one service, stopping a service, inspecting logs, and killing the process manager. These commands are useful for distinguishing a web-service startup problem from a replay retrieval or parsing problem.

pm2 list
pm2 start ecosystem.config.js
pm2 stop web
pm2 logs web

The Compose file defines containers for PostgreSQL, Cassandra, MinIO, Redis, the parser, and Core. The `core` service publishes both `5000:5000` and `5100:5100`. Port 5000 is identified by the README as the default API port. The repository files do not explain the purpose of port 5100, so operators should not assume that it is a second public API port without checking the service configuration.

For direct PostgreSQL access, the package file defines this command:

npm run psql

It runs `psql` inside the `odota-postgres` container against the `postgres` user and `yasp` database. The package also provides Redis inspection helpers such as `rediskeys`, `resetpicks`, and `resetrecords`, but these commands operate on existing keys and should not be treated as harmless status queries. The Compose configuration uses PostgreSQL 9.5, Cassandra 5.0, and Redis 7, so a deployment based on the repository is tied to those declared images unless the configuration is changed deliberately.

Limitations, alternatives, and license implications

The largest limitation is operational. The README's quickstart requires Docker, Compose, multiple containers, configuration values, and a Java parser image. Replay parsing also depends on Steam account credentials and access to the Dota Game Coordinator. The documentation warns that the account used for parser login cannot be logged in through the Steam client at the same time and that Steam Guard must be disabled. That is a deployment boundary, not a small configuration preference.

A real alternative is to build a simpler API around Valve's WebAPI without adding automated `.dem` parsing, PostgreSQL, Cassandra, Redis, MinIO, and separate Node.js workers. Such an application would need less infrastructure, but it would not provide the same parsed replay data path or the OpenDota API contract. Another alternative is to use the public OpenDota deployment instead of operating Core. The README says a public deployment is maintained by The OpenDota Project, but it does not state its service-level terms or suitability for a particular workload.

The repository is licensed under MIT, and `package.json` also identifies the package as MIT licensed. That is useful for understanding the project's stated licensing model, but it is not legal advice. Operators still need to review the repository license, image licenses, and dependencies for their own deployment. The repository has no GitHub releases, so version selection is based on the source tree and package version `31.1.0` rather than a documented release stream. The last push was on 2026-10-15, but a recent push alone does not document upgrade compatibility or database migration policy.

Editorial conclusion

OpenDota Core is appropriate for developers who need a self-hosted OpenDota API, contributors working on replay retrieval, or teams already prepared to operate several databases and background services. It is a poor fit for a lightweight match lookup service or for someone who expects replay parsing to work without Steam credentials and the parser runtime. Before adoption, verify that the required `.env` values are available, decide whether replay parsing is necessary, and confirm that the chosen host can run the full `docker-compose.yml` stack on ports 5000 and 5100.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. odota/core on GitHub
4. Project website
5. README