Tracearr: one dashboard for Plex, Jellyfin and Emby
Real-time monitoring for Plex, Jellyfin, and Emby servers. Track streams, analyze playback, and detect account sharing from a single dashboard.
At a glance
- What is it?
- Tracearr is an AGPL-3.0 self-hosted monitoring platform that tracks streams, playback analytics and account sharing across Plex, Jellyfin and Emby from a single install. It is the right tool if you run more than one media server; it is overkill if you run one.
- Who is it for?
- Adopt Tracearr if you run two or more of Plex, Jellyfin and Emby, or if you already want trust scores and automations rather than a read-only history page. Skip it if you run Plex alone and Tautulli already answers your questions, since Tracearr adds PostgreSQL with TimescaleDB, Redis and a second process to keep alive for features you will not use.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The multi-server gap Tracearr is built to fill
The README states the problem plainly: Tautulli only works with Plex, Jellystat only works with Jellyfin and Emby, so anyone running more than one of the three ends up with more than one dashboard. Tracearr's answer is a single install that connects to all three, presents active streams and server health on one page, and matches media across servers into one catalog record per title using IMDb, TMDB or TVDB ids.
The audience is narrower than "anyone with a media server". If you run Plex only, Tracearr duplicates what Tautulli already gives you and adds two stateful services to maintain. The project earns its place when your users span servers, when you want to see that the person on Plex and the person on Jellyfin are the same human, or when you want enforcement rather than observation. Identity merging and trust scores are the features that have no direct equivalent in the single-server tools.
How the pieces fit: Fastify, TimescaleDB, Redis and an SSE plugin
The repository is a pnpm and Turborepo monorepo with apps and packages directories, written in TypeScript, with Fastify on the server side and React in the web app. The topics list names react-native as well, which lines up with the mobile push destination the README mentions.
State lives in PostgreSQL with the TimescaleDB extension, and Redis is used for more than caching: the .env.example explains that when DATABASE_POOL_MAX is unset, the app reads max_connections from Postgres, counts live Tracearr instances through the shared Redis, and gives each instance a fair share capped at 50. That is a deliberate design choice for people running several replicas behind one database, and it means Redis is effectively required for sane pool sizing rather than optional.
The interesting asymmetry is telemetry collection. Plex reports its own CPU, memory and bandwidth numbers. Jellyfin and Emby do not, so Tracearr reads them through a separate project, the Tracearr SSE plugin. Without that plugin installed on those servers, your Jellyfin and Emby health charts have nothing to draw. The README states this directly; it is not a bug you can configure around.
Installing Tracearr with Docker Compose and reading the first dashboard
The README points at tracearr.com for the feature tour and docs.tracearr.com for the manual, and the container image is published to ghcr.io/connorgallopo/tracearr. The repository also ships a development compose file, and the root package.json exposes a script that wraps it. That script builds the dev stack from docker/docker-compose.dev.yml:
pnpm docker:upFor a real deployment you will be writing your own compose file or following the docs, because the checked-in one is the development variant. Either way you need to supply the environment the app expects. The .env.example gives the shape of it:
DATABASE_URL=postgres://tracearr:tracearr@localhost:5432/tracearr
REDIS_URL=redis://localhost:6379
PORT=3000
HOST=0.0.0.0
JWT_SECRET=your-secret-key-change-in-production
COOKIE_SECRET=your-cookie-secret-change-in-productionThe file's own comments say to change the secrets in production, and that is not boilerplate: JWT_SECRET and COOKIE_SECRET are the auth material for the whole instance. BETTER_AUTH_SECRET is optional and, when unset, is derived deterministically from JWT_SECRET so upgrades do not need a new variable. If you run more than one instance, every instance must share the same value or the same JWT_SECRET. The port is 3000 by default, which is the number people search for when the UI does not come up behind a reverse proxy.
Once it is running, the first useful stop is Settings, where you generate an API key, then the interactive Scalar reference at /api-docs on your own instance. If you already have history in Tautulli, a Jellystat backup file, or the Jellyfin and Emby Playback Reporting plugin, the import path brings it across rather than starting from zero.
Trust scores and automations are where the opinionated design shows
Every account starts at a trust score of 100. Violations lower it, automations can adjust, set or reset it, and an identity's score is the lowest among its active accounts. That last rule is the design decision worth noticing: merging a Plex login and a Jellyfin login into one identity cannot be used to launder a bad score, because the worst account wins. The README calls this out explicitly, and it is the kind of constraint that tells you the author thought about the failure mode.
Automations follow a trigger, condition, action shape. Eighteen triggers cover sessions, accounts, library changes, server health, update availability and newsletter results. Actions notify, adjust trust, message the client or stop the stream, and an if action branches. Twenty-two templates ship built in, including impossible travel, too many streams at once, simultaneous locations, device velocity, geo restrictions and stop-paused-streams. Any automation exports to a share code another instance can paste in, which is a small feature with real consequences: it is how a community ends up trading rule sets instead of screenshots.
The trade-off is that stop-stream and trust adjustments are enforcement, not monitoring. A badly written condition can cut off a paying user mid-film. The templates lower that risk, but nothing in the README describes a dry-run mode, so test new rules against a low-stakes account first.
Where Tracearr is the wrong tool
Three cases stand out. First, a single Plex server. You would be adding PostgreSQL with TimescaleDB, Redis and a Node process to reproduce what Tautulli already does, and the multi-server catalog and identity merging that justify the stack stay unused.
Second, a Jellyfin or Emby-only setup where you want the health charts. Those numbers come from the Tracearr SSE plugin, a separate repository. If you are unwilling to install a second component on your media servers, the per-server CPU, memory and bandwidth panels stay empty and you are left with session tracking and analytics only.
Third, anyone who needs a managed service. Tracearr is self-hosted, the stream map basemap ships inside the container specifically so there are no tile keys and no third-party tile requests, and the whole point is that your viewing data stays on your hardware. If you do not want to run Postgres and Redis, this is not the project for you. The README does not document a rollback path for the TimescaleDB extension upgrade either, and the .env.example warns that the update is one-way: rolling the image back afterwards breaks the database. That is a real operational hazard for anyone who upgrades images casually.
Tracearr vs Tautulli and Jellystat: the actual difference
The comparison is not about which dashboard looks better. Tautulli is a Plex-only monitor with a long history and a large body of community scripts; it reads Plex's own reporting and has no concept of a second server, so cross-server identity merging and a unified catalog are out of scope by construction. Jellystat covers Jellyfin and Emby and, like Tautulli, stays inside that boundary.
Tracearr's difference is the join. One title matched by IMDb, TMDB or TVDB id with each server's copies attached, one person assembled from a Plex login and a Jellyfin login, and one trust score that is the worst of that person's accounts. Everything else (session history, geolocation with ASN and postal code, transcode versus direct play, the storage and watch analytics pages) is table stakes that the single-server tools largely cover too.
The practical consequence: if you migrate from Tautulli, you are not replacing a dashboard, you are adding a layer above two or three of them. The README's own import path for Tautulli history exists precisely because people arrive with data already and do not want to lose it.
Licence, upgrade cost and what the repository tells you about maintenance
Tracearr is AGPL-3.0. For a homelab instance the practical effect is minimal: you can run it, modify it and self-host it. The copyleft obligation attaches when you let other people interact with a modified version over a network, at which point you must offer them the corresponding source. That is a real consideration for anyone thinking about building a hosted service on top of it, and it is the reason some teams will not touch it. This is a description of the licence text, not legal advice; read LICENSE and talk to a lawyer if the distinction matters to your business.
Upgrade cost is dominated by the database, not the app. The image can be swapped freely, but the TimescaleDB extension does not follow the image: TIMESCALEDB_AUTO_UPDATE is off by default because the extension update is one-way and needs ALTER EXTENSION privilege, and when it is off Tracearr logs a warning if the versions drift. So a routine image bump can leave you in a state where the app warns about a version mismatch you have to resolve deliberately. Budget for that rather than treating Tracearr like a stateless container you can pull and restart.
On activity: the repository is not archived, and the last push was on 2026-09-17, with v2.3.0 released on 2026-09-15 after a run of beta tags. The project also carries Crowdin configuration and a translations check in the CI script, which signals ongoing localisation work rather than a frozen codebase.
Editorial conclusion
Adopt Tracearr if you run two or more of Plex, Jellyfin and Emby, or if you already want trust scores and automations rather than a read-only history page. Skip it if you run Plex alone and Tautulli already answers your questions, since Tracearr adds PostgreSQL with TimescaleDB, Redis and a second process to keep alive for features you will not use. Before committing, verify three things on your own hardware: that the Tracearr SSE plugin is installed for your Jellyfin and Emby servers, otherwise per-server CPU, memory and bandwidth charts stay empty; that TIMESCALEDB_AUTO_UPDATE is left off unless you accept a one-way extension upgrade that breaks the database if you roll the image back; and that you are comfortable with AGPL-3.0 if you ever plan to expose a modified Tracearr to other people over a network.
Frequently asked questions
What are the key differences between Tracearr and Tautulli?
Tautulli only works with Plex, while Tracearr connects to Plex, Jellyfin and Emby in one install and presents a single dashboard and catalog across them. Tracearr also adds trust scores and automations that can adjust trust, message a client or stop a stream, which Tautulli does not do.
What are the key differences between Jellystat and Tracearr?
Jellystat only works with Jellyfin and Emby, so a Jellyfin user with a Plex server alongside it needs a second dashboard. Tracearr covers all three servers and merges a person's accounts across them into one identity whose trust score is the lowest of its active accounts.
How do I install Tracearr with Docker Compose?
The container image is published to ghcr.io/connorgallopo/tracearr, and the repository ships a development compose file at docker/docker-compose.dev.yml, wrapped by the pnpm docker:up script. You supply DATABASE_URL, REDIS_URL, JWT_SECRET and COOKIE_SECRET, and the docs at docs.tracearr.com cover the deployment path.
Does Tracearr have a mobile app or Android client?
The README lists mobile push among the notification destinations, and react-native appears in the repository topics. The README does not describe a standalone Android or iOS application, so treat the phone experience as notifications rather than a full client.
Can I use the Tracearr API from my own scripts?
Yes. The README describes a key-authenticated REST API with v1 and v2, with keys generated under Settings. The API reference lives at docs.tracearr.com/api, and each instance serves an interactive Scalar page at /api-docs.
Community notes