Dreeve: a self-hosted PHP dashboard for Strava and FIT/TCX/GPX activity data

The problem Dreeve solves, and who it is actually for

Strava holds the canonical copy of most amateur cyclists' and runners' training history. That is fine until you want to query it, keep it after you stop paying, or look at it through a lens Strava does not offer. Dreeve, described in its README as "a self-hosted, open-source dashboard for your sports and fitness data," is the answer to that: you run it yourself, you own the database, and the analysis layer sits on your hardware. The project was formerly known as Statistics for Strava, which tells you where the original audience came from. The current name drops the dependency in the title, and the feature list backs that up: activities can arrive either from a connected Strava account or from raw FIT, TCX and GPX files. That second path matters. It means a Garmin or Wahoo user who never touches Strava can still run the thing, and it means a Strava user has an exit route if the API terms change. The intended user is someone comfortable with Docker and a browser-based admin panel, not someone looking for a hosted service. There is no mention of a managed offering anywhere in the README.

What the feature list covers, and where it is thin

The README enumerates the modules: a dashboard, an activities list, a monthly view with an interactive calendar, gear statistics, maintenance tracking, Eddington numbers, segments and efforts, a heatmap, a milestones timeline, a year-in-review called Rewind, Strava challenges, activity photos, user badges, PWA support, and an AI workout assistant. The breadth is real, and several of these are the kind of thing people build spreadsheets for. Maintenance tracking and gear stats together are the most useful part for anyone with more than one bike or a rotating set of shoes, because wear tracking is exactly what Strava does poorly. Automation rules are the other notable item: the README says they handle "gear tracking, commuting flags, and more," which implies rules run against imported activities and mutate their metadata. That is a sensible design, but the README does not document the rule syntax, the available conditions, or whether rules re-run when an activity is edited. The AI workout assistant is listed without any statement of which model provider is used or what data leaves the instance. For a self-hosted tool whose selling point is data ownership, that omission is worth resolving before you enable it.

How data gets in: Strava connection versus file import

There are two ingestion paths and they behave differently. The first is a Strava account connection, which the README lists as an alternative to file import. The second is direct import of FIT, TCX or GPX files. The file path is the more predictable one: those formats are stable, and once parsed the activity lives in your database with no further network calls. The Strava path depends on Strava's API, its rate limits and its OAuth flow, none of which the README describes. Based on the repository layout alone, the application is PHP, so parsing and storage happen server-side, with the browser acting as the presentation layer through the admin panel and dashboard. What the README does not say is whether imported files are stored alongside the parsed records or discarded after parsing, and whether a re-import of the same file creates a duplicate. Both questions matter if you plan to bulk-load years of history. The documentation site at docs.dreeve.app is where installation and configuration are covered, per the README, so that is the place to check before pointing it at an archive of exports.

Getting it running: Docker, an admin panel, and a documentation site

The README points at two things for setup: a Docker Hub image published under robiningelbrecht/dreeve, and the documentation at docs.dreeve.app. It does not include a docker run command, a compose file, or a list of environment variables, so the exact invocation has to come from the docs rather than from this article. What can be stated from the README is the shape of the operation: you run a container, you open a browser-based admin panel, and you manage activities, gear and "every setting" from there. That admin panel is the configuration surface, which is a deliberate choice and a reasonable one for a tool aimed at people who do not want to hand-edit YAML. It also means the configuration is not fully reproducible from a file in version control unless the docs describe an export path. The README does not say whether settings can be exported or seeded. If you run more than one instance, or you rebuild the container often, check that first. The documentation link is the only setup reference given, so treat the README as a feature index rather than an installation guide.

The AI workout assistant is the part to be sceptical about

One line in the feature list reads: "AI workout assistant - Get personalized workout suggestions and insights powered by AI." That is the whole description. No provider is named, no model, no statement about whether activity data is sent to an external service or processed locally, and no note on whether the feature can be disabled at build time. For a self-hosted application whose premise is that your fitness data stays on your hardware, an undocumented outbound path is the single largest thing to verify. It is not necessarily a problem: many self-hosted tools offer optional cloud-backed features behind a toggle. But the README does not confirm that a toggle exists, and the admin panel is described as managing "every setting," which suggests there is one somewhere. Until you read the configuration docs, assume the assistant may transmit data and leave it off. The rest of the feature list, from Eddington numbers to the heatmap, is computed from data you already hold and carries no such ambiguity.

Where Dreeve is the wrong tool

Dreeve is not a training platform. It is a dashboard over data you already recorded. If you want structured intervals pushed to a head unit, or a coach-facing plan builder, this is not that, and nothing in the README suggests otherwise. It is also not a general-purpose health tracker: the topics list fitness, health and statistics, but every import path named is an activity file format or Strava, so sleep, HRV and nutrition data have no documented route in. Multi-user support is another gap. The README describes an admin panel and a dashboard in the singular, with no mention of accounts, roles or per-user data separation. If two people in a household both ride, check the docs before assuming you can host one instance for both. Finally, the AGPL-3.0 licence has a practical consequence: if you modify Dreeve and let other people interact with it over a network, the licence's network clause generally requires you to offer them the modified source. For a private instance that changes nothing. For a hosted or club-facing deployment, it changes what you owe your users. That is a description of the licence, not legal advice; read the LICENSE file in the repository if the distinction matters to you.

Alternatives and the difference in approach

The obvious comparison is Strava itself, and the difference is not just who owns the database. Strava is a social network with analytics attached; Dreeve is an analytics tool with no social layer described in the README. Segments and challenges appear in both, but in Dreeve they are views over your own imported data, not a live leaderboard against other people. If the competition is what motivates you, self-hosting removes it. A second comparison is the spreadsheet or notebook route that many cyclists already use: export the FIT files, parse them, chart them. That approach has no admin panel, no maintenance tracking and no PWA, but it also has no container to update and no licence obligations. Dreeve's value is that it packages the boring parts, parsing, gear association, calendar views, into something you configure in a browser. A third comparison is the broader self-hosted fitness category, which the README does not name. Dreeve's distinguishing feature within that space is the combination of Strava import and raw file import in one tool, plus automation rules for gear and commuting flags. Tools that only ingest files cannot migrate an existing Strava history; tools that only read Strava cannot outlive it.

Maintenance cost, release cadence and what to check first

The release history shows v5.3.0, v5.3.1 and v5.3.2 within roughly two weeks of each other in August and September 2026, and the last push to master is dated 2026-09-10. That is an active cadence, and it has a cost: patch releases at that frequency mean you need a repeatable upgrade path, which for a Docker deployment means pinning a tag rather than tracking latest. The README does not describe a database migration process or a backup procedure, so both need to come from docs.dreeve.app. The AGPL-3.0 licence permits commercial use and modification, and requires that modified versions offered over a network carry their source with them. There is no paid tier mentioned, and the README instead links to a Buy Me a Coffee page, which suggests funding comes from donations rather than a hosted product. That matters for durability: a donation-funded project with a single maintainer, as the name-origin note implies, has a different continuity risk than one with a company behind it. Before you migrate years of history into it, verify the upgrade and backup story in the docs, confirm how the Strava connection is refreshed, and decide whether the AI assistant stays off.

Editorial conclusion

Dreeve fits self-hosters who already run Docker and want Strava or file-based activity data in their own database, with gear tracking and automation rules as the differentiating features. It is the wrong choice if you want a hosted service, or if you need a documented HTTP API for third-party clients, since the README lists neither. Before committing, verify three things on docs.dreeve.app: the exact Docker image tag and volume layout, how the Strava connection is authenticated and refreshed, and what the AI workout assistant sends to a third party, because the README does not say.

Official sources

1. dreeveapp/dreeve on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases