wger: a self-hosted Django stack for workouts, nutrition and body measurements

What wger replaces, and for whom

Most fitness apps are accounts on someone else's server. You log sets, meals and body weight into a database you cannot query, export or move, and the vendor decides when the schema changes. wger is the opposite arrangement: the README describes it as a free workout and fitness manager, licensed AGPL-3.0 or later, and the homepage is a live instance at wger.de that you can ignore entirely if you run your own. The audience is narrow and specific. It is for people who want workout routines with automatic weight progression rules, a diet log tied to a food database, and body measurements in one place, and who are willing to run a Python web application to get that. The README also mentions basic gym management features and multi-user support, which shifts the target from a single lifter to a small gym or a group that wants shared exercise definitions and separate user accounts. If you only want to count calories on your phone, the self-hosting cost is not justified. If you want your training history in a database you can join against, it is.

The architecture is a Django project with a Flutter front end

The repository layout tells you most of what you need. wger is a Python project whose top-level package contains a core app, and the README lists a REST API as a first-class feature rather than an afterthought. That is the load-bearing design decision: the web interface and the mobile clients are both consumers of the same API, which is why the README can advertise Android, iOS, F-Droid and Flathub builds under the package name de.wger.flutter. The data model implied by the feature list has three roughly independent domains. Workout routines hold exercises with progression rules attached. Nutrition entries reference a food database that the README attributes to Open Food Facts, which means ingredient and calorie data come from an external catalogue rather than being typed in by hand. Body weight and custom measurements are a separate time series. Progress photos are stored as uploads, which is the part that changes your operational profile: you are now responsible for binary object storage, not just rows. The exercise wiki is content as much as code, and the README is explicit that exercise and ingredient data carry Creative Commons terms per entry while the application code is AGPL-3.0-or-later. Those are two different licences in one deployment, and mixing them up is a real mistake.

Getting an instance up: docker compose, then read the compose file

The README is deliberately terse here. It states that hosting your own instance is basically a docker compose up -d away, and points to a separate repository, wger-project/docker, plus the Docker installation page at wger.readthedocs.io/en/latest/installation/docker.html. That is the whole quickstart. The honest reading is that the README gives you the command but not the configuration surface: database credentials, the secret key, allowed hosts, and the media and static file paths all live in the compose file and the documentation, not in this repository's README. Before you run that command on anything you care about, open the compose file and enumerate the services and volumes it declares. The volumes are the answer to where your training history actually lives. The documentation also covers API usage and development guidelines, so the API documentation is the place to look if you intend to write against the REST endpoints rather than use the bundled Flutter app. For development, the README points at a contribution guide rather than describing a local setup, which suggests the supported path is the containerised one.

Where the self-hosted model bites

Three constraints follow from the material. The first is operational: a Django application with a relational database, a media directory for progress photos and a set of static assets is not a static site. You own backups, upgrades and the database. The release cadence visible in the repository is roughly every two months (2.5 in April 2026, 2.6 in June, 2.7 in September), which is frequent enough that an unmaintained instance drifts quickly. The second is the AGPL-3.0 licence. It is a strong copyleft licence with a network clause, and the practical consequence is that if you modify wger and let other people use it over a network, the source of your modified version has to be available to those users. For a private instance used by your household this rarely matters. For a commercial gym that wants to fork the interface and keep the changes, it is the deciding factor, and it is worth reading the licence text rather than a summary. The third is data provenance. Nutrition logging depends on the Open Food Facts catalogue, so the quality and coverage of that external data set bounds what you can log, and the README does not describe an offline fallback. Where the documentation is thin, the README simply defers to readthedocs, and you should treat that as a signal to read the docs before assuming a feature behaves the way the bullet list implies.

How it differs from a hosted tracker such as Strong or MyFitnessPal

The comparison that matters is not feature parity, it is who holds the database. A hosted tracker gives you an account, a mobile app and a support queue, and in exchange you accept that the export format is whatever the vendor offers and that the service can change terms or shut down. wger inverts every one of those. You get a REST API documented at wger.readthedocs.io, which means you can pull your own data with a script instead of requesting an export. You get the Flutter client from F-Droid or Flathub if you want an app-store-free build, which the hosted alternatives generally do not offer. You also get the bill: the server, the database, the backups and the upgrade cycle. The second comparison is against writing your own tracker. wger already has the exercise catalogue, the Open Food Facts integration and the progression rules, and the README treats the exercise wiki as something you contribute to rather than seed yourself. Rebuilding that content layer is the expensive part, not the CRUD screens. The trade-off is that you inherit someone else's schema and someone else's release schedule.

Maintenance, upgrades and licence obligations

The material supports a few concrete statements about cost. Releases land every couple of months, so a self-hosted instance needs a repeatable upgrade path rather than a one-off install, and the docker compose file in wger-project/docker is the artefact that path is built around. Because progress photos are stored as uploads, your backup routine has to cover the media volume as well as the database dump; a database-only backup loses the gallery. Translation is handled outside the repository through Weblate, so localisation updates arrive through that pipeline rather than through a code change you make yourself. On licensing, there are three regimes in one deployment: AGPL-3.0-or-later for the application code, Creative Commons for exercise and ingredient data as noted per entry, and CC-BY-SA-4.0 for the documentation. The AGPL network clause is the one with operational consequences for anyone exposing a modified instance to other users. This is not legal advice, and if you plan to run wger as part of a business, the licence text and your own counsel are the right references, not a README badge.

Who should run this, and what to check first

wger fits the case where the data matters more than the polish: a lifter or a small gym that wants routines, a nutrition log and body measurements in one queryable place, and that already runs containers. It does not fit someone who wants a managed service, and it does not fit a team that wants to modify the code and keep the modifications private while exposing the result to users, because the AGPL-3.0 network clause points the other way. The verification list before you commit is short and specific. Read the compose file in wger-project/docker and write down every volume it declares, because that list defines your backup scope. Read the Docker installation page at wger.readthedocs.io/en/latest/installation/docker.html for the environment variables the stack expects, since the README does not list them. Then read the API documentation and confirm the endpoints you need exist, because the README advertises a REST API without enumerating it. If those three checks pass, the remaining question is whether you will actually keep the instance upgraded at a two-month cadence.

Editorial conclusion

Adopt wger if you want a multi-user fitness and nutrition tracker that you control, and you are comfortable operating a Django application plus its database and static files. Do not adopt it if you need a managed service with an uptime commitment, or if the AGPL-3.0 network clause conflicts with how you plan to expose a modified instance. Before committing, verify two things against the docker compose file in wger-project/docker: which services the stack starts and which volumes hold your data, and whether the REST API surface documented at wger.readthedocs.io covers the client integrations you actually need.

Official sources

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