Overview
From a personal quest tree to a progression platform
Tarkov Tracker began as a personal tool for understanding a new Escape from Tarkov season. The original idea was an interactive tree showing how hundreds of quests connect through prerequisites, trader relationships, item requirements, and map objectives.
Using it with friends revealed a broader problem. New players needed to understand what unlocked next, while experienced players wanted to organize progression without constantly moving between the game, wiki pages, and external tools. The project grew into an authenticated application with personal progress, tracked quests, search and filtering, prerequisite discovery, required items, maps, and a dashboard focused on the next useful action.
Problem
Turn a complicated progression system into an actionable next step
Individual quest pages can explain one objective, but they do not clearly show how that quest fits into the larger progression system. A player may know what they want to unlock without knowing which earlier quest, item, trader, or map deserves attention now.
The application needed to preserve those relationships while presenting them at the right level: a graph for understanding progression, detailed views for investigation, and a dashboard for answering what to work on next.
Constraints
Model the whole system without forcing users to confront all of it at once
Graph scale
Represent hundreds of interconnected quests without turning a technically correct graph into an unusable wall of nodes.
Upstream resilience
Keep the application useful when the tarkov.dev GraphQL service is slow or unavailable.
Multiple game modes
Treat regular, PvE, and seasonal PvP progression as distinct datasets with overlapping identifiers.
User boundaries
Share one canonical game dataset while keeping every player's progression and preferences private.
Spatial data
Translate raw objective coordinates into useful map positions, including locations with multiple floors.
Production operation
Build a repeatable, self-hosted delivery path rather than leaving the application as a local prototype.
Architecture
Own the data path from source datasets to player decisions
The runtime application does not depend on a live tarkov.dev request. A custom importer synchronizes source datasets into PocketBase, where global game definitions remain separate from authenticated user progression. Next.js serves the application and React Flow renders the relationship graph. The production image moves through GitLab's registry to a self-hosted runner, with Nginx and Certbot handling the public edge.
01
tarkov.dev datasets
Provide quests, traders, items, maps, hideout data, crafts, barters, translations, and objective coordinates.
02
Importer and PocketBase
Normalize and upsert mode-aware records while retaining the complete translated source payload.
03
Next.js application
Combines shared game data with user-scoped progress, then presents the tree, dashboard, details, and maps.
04
Self-hosted delivery
Docker, GitLab CI/CD, the container registry, and a runner deploy exact commit images behind Nginx and TLS.
Technical decisions
Treat quest progression as a graph
Make relationships the core model
Use React Flow nodes and edges to answer what a quest requires, what it unlocks, and how far away a target is.
Own a local copy of game data
Import tarkov.dev datasets so upstream availability and latency are not part of the application's runtime dependency chain.
Preserve raw and modeled data
Extract frequently queried fields while retaining the complete translated source object in a payload field for future needs.
Separate definitions from progression
Keep canonical quest records global and store each authenticated user's completed and tracked quests independently.
Surface prerequisites early
Show unfinished prerequisites and their required items so a locked tracked quest still produces a useful recommendation.
Theme through semantic tokens
Use CSS variables so Tactical Light, USEC Command, and Iron Sights can change the interface without duplicating components.
Implementation
Connect ingestion, progression, maps, and delivery
Mode-aware ingestion
The TypeScript/Node pipeline imports quests, traders, items, maps, hideout data, crafts, barters, and translations, upserting by Tarkov ID and game mode.
Progression dashboard
Tracked goals are traversed backward through unfinished prerequisites so the dashboard can expose currently actionable quests and required items.
Map operations view
Objective X/Y/Z coordinates are projected onto community-maintained SVG maps; multi-level locations can isolate a floor while retaining faint ground-floor context.
Commit-addressable deployment
The pipeline validates the project, builds and tags a production image, publishes it to GitLab's registry, and has a self-hosted runner replace the application container with that exact commit.
Challenges
Completeness and usability pulled in different directions
Large graph navigation
Search, trader filters, draggable navigation, and detailed views made the complete graph explorable without asking it to solve every workflow.
Unreliable external data
An upstream GraphQL outage expanded the work into schema design, normalization, translations, upserts, and synchronization—but produced a more resilient runtime.
Mode identity
Regular, PvE, and seasonal PvP records required game mode to become part of identity and querying rather than merely a display filter.
Coordinate projection
Raw world positions had to be aligned with visual map geometry and building levels before they became meaningful to a player.
Multi-user evolution
Moving beyond a personal tool introduced OAuth callbacks, user-scoped state, persistent preferences, and database access rules.
Production boundaries
Operating the service required deliberate handling of configuration, secrets, repeatable images, network exposure, TLS, and rollback-friendly releases.
Results
A deployed platform that makes progression easier to act on
Connected progression
A complete interactive dependency tree, search, trader filtering, and quest details expose how progression fits together.
Personal planning
Google OAuth, persistent completion state, tracked quests, and automatic prerequisite discovery support individual players.
Actionable context
Required items and map-based objective views reduce the need to reconstruct the next step across several outside resources.
Dataset breadth
Regular PvP, PvE, and seasonal progression can be refreshed through an automated ingestion process.
Flexible presentation
Multi-floor maps and multiple user-selectable themes adapt the interface without changing its underlying content model.
Repeatable production
Containerized builds and self-hosted GitLab delivery move a validated, commit-tagged image into production.
Lessons learned
Use the system, find the real friction, and let that shape the architecture
The tree and dashboard solve different jobs. The graph is best for understanding relationships; the dashboard is better at deciding what matters now. Recognizing that distinction prevented one interface from carrying every responsibility.
Owning the synchronization path added work but removed an unreliable service from the runtime. Production deployment created another useful boundary: application code, data, secrets, public networking, and TLS each needed a clear owner.
Most importantly, the project reinforced how I prefer to build software: start with a problem I understand, ship the smallest useful version, use it, and let observed friction—not imagined scale—drive the next decisions.
What's next
Keep improving the path from data to the next useful action
Future work can deepen graph navigation, make ingestion freshness and failures more visible, and improve operational observability. Those additions should continue serving the original question rather than expanding the product for its own sake.