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

What wger replaces, and for whom

Most workout trackers are subscription services. Your sets, your body weight history and your food log sit on someone else's server, and the export path is whatever the vendor decides to build. wger takes the opposite position: the README describes it as a "free workout and fitness manager" that is self-hostable with Docker, so the database lives wherever you put it.

The audience is narrow and specific. It fits people who already run a server, or who are willing to learn, and who want training data, nutrition data and measurements in one schema they can query. The project also ships a REST API and a set of Flutter clients for Android, iOS, F-Droid and Flathub, which means the self-hosted instance is not a web-only experience. A gym or a trainer who wants several people under one installation is also in scope: the README lists multi-user support with basic gym management features.

It is a worse fit for someone who wants to log a workout in ninety seconds and never think about infrastructure. Django plus Postgres plus Redis plus a Celery worker is a real stack, and the README's claim that hosting is "basically just a docker compose up -d away" is true only after you have read the separate docker repository and its documentation.

The Django app, the API and the Flutter clients

The repository layout is a conventional Django project: manage.py at the top level, a settings/ package, a wger/ package holding the apps, and pyproject.toml declaring the dependencies. Python 3.12 is the floor, and the classifiers list 3.12 through 3.14.

The dependency list is where the architecture becomes visible. djangorestframework and drf-spectacular provide the REST API and its schema, djangorestframework-simplejwt handles token authentication, and django-cors-headers exists so the Flutter clients and other front ends can talk to the API from a different origin. Celery with Redis is present for background work, flower is listed for monitoring those tasks, and django-redis backs the cache. django-simple-history keeps an audit trail of model changes, and django-allauth with the mfa and idp-oidc extras covers login, multi-factor authentication and OpenID Connect identity providers.

Storage is pluggable. boto3 and django-storages appear together, which is the standard pairing for keeping user-uploaded images in S3-compatible object storage rather than on the application server's disk. That matters because the README advertises a progress gallery where users upload photos. easy-thumbnails handles the derived image sizes.

The front end is server-rendered Django templates with htmx and Bootstrap 5.3.8, per package.json, plus a React component package pulled in as a dev dependency. There is no separate JavaScript SPA to deploy. The npm scripts section contains a single Sass build step that compiles main.scss into bootstrap-compiled.css.

Running wger with Docker and logging a first workout

The README points self-hosters at a separate repository, wger-project/docker, and its compose file, with fuller instructions in the online documentation under installation/docker. The repository you are reading is the application, not the deployment bundle, so the compose file is not in this tree.

The README gives the short version. From a checkout of the docker repository, the documented command is:

docker compose up -d

After that, the documented path is the web interface on the host you configured. The first account you create becomes the user you log workouts against. If you are deploying this for other people, check the registration and recaptcha settings before you expose the port, because django-recaptcha is in the dependency list and the documentation covers the configuration.

Once you are logged in, the workflow the README describes is: build a routine, attach exercises from the built-in exercise wiki, and let the automatic weight progression rules adjust the loads. Nutrition is a separate area backed by a food database from Open Food Facts, and body weight plus custom measurements live alongside it. Progress photos go into the gallery.

For scripted access, the API is the entry point. The project documents it at wger.readthedocs.io, and drf-spectacular means the schema is generated from the code rather than maintained by hand. The documentation is the place to confirm the current endpoint paths and authentication scopes; the README itself does not enumerate them.

If you prefer to run the application outside containers, pyproject.toml is the source of truth for the Python side and requires Python 3.12 or newer. The README does not walk through a bare-metal install, so treat the Docker route as the supported one.

What the self-hosted deployment actually costs you

The honest limitation is operational, not functional. A wger instance is a Django application, a relational database, a Redis instance, a Celery worker and, if you enable it, an object storage bucket. That is five moving parts for a personal fitness log. Backups are yours to design, and the README does not document a rollback procedure or a migration path between versions, so an upgrade that goes wrong is recovered from whatever snapshot you took.

Background processing is a second constraint. Celery is in the dependency list, which means some work happens outside the request cycle. If the worker is not running, the web interface may still respond while the queued work does not complete. The documentation covers the worker configuration; the README does not warn about this failure mode at all.

There is also a content question. The exercise wiki and the ingredient data are community-maintained, and the licence section states that exercise and ingredient data is Creative Commons with terms on the individual entries. Coverage and quality will vary by exercise and by food. The Open Food Facts dependency is the same story: the food database is only as complete as its contributors have made it, and a self-hosted instance inherits whatever gaps exist upstream.

Finally, consider whether you are the right operator. If you do not want to run Postgres and Redis, if you do not want to monitor a task queue, and if nobody in your household will notice when the container stops, a hosted tracker is the better decision. wger's value proposition is control, and control has a maintenance bill attached.

How wger differs from a plain spreadsheet or a hosted tracker

The obvious alternative is a spreadsheet. A spreadsheet gives you full ownership of the file, needs no server, and can be shaped to any routine you like. What it does not give you is the exercise wiki, the Open Food Facts lookup, automatic weight progression rules, or a mobile client that syncs to the same data. It also does not give you a REST API that other tools can call. If your tracking is a handful of columns and you never want to run a service, the spreadsheet wins on every axis except convenience of data entry on a phone.

The other alternative is a commercial hosted tracker. Those remove the operational burden entirely and typically have polished mobile apps. The trade is the one wger exists to avoid: your data is on their infrastructure, subject to their export options and their pricing decisions. wger's REST API is the escape hatch a hosted product may not offer at all.

A third comparison is worth naming for anyone with an existing Django deployment: the components wger uses are not exotic. django-allauth, Celery, Redis and django-storages are standard choices, so an operator who already runs Django services will find the shape familiar. That is an argument for wger over a bespoke tracker, not over a spreadsheet.

Licence, versions and what an upgrade involves

wger is licensed AGPL-3.0-or-later. The practical consequence, stated plainly and without legal advice, is that the AGPL's network clause applies to software offered to users over a network. If you modify wger and let other people use your modified instance, the licence expects you to make the corresponding source available to them. Running an unmodified instance for yourself or your household does not raise that question in the same way. The documentation is CC-BY-SA-4.0 and the exercise and ingredient data is Creative Commons per entry, so the three layers carry different terms. If you plan to redistribute anything, read LICENSE.txt and the individual data entries rather than relying on this summary.

On maintenance, the repository is not archived and the last push was on 2026-09-06. Releases are frequent: 2.5 on 2026-04-15, 2.6 on 2026-06-17, and 2.7 on 2026-09-03. That cadence is good for fixes and bad for anyone who wants to pin a version and forget it, because three minor releases in five months means three rounds of reading the changelog.

Upgrade cost is mostly the usual Django work: apply migrations, restart the application and the Celery worker, and confirm that your settings still match what the new release expects. The repository contains a CHANGELOG.md, which is where release-specific notes live. There is no documented downgrade path, so the practical preparation is a database dump before you pull a new image. Note also that package.json still carries version 2.6-alpha1 while the release tags show 2.7, which is a reminder that the JavaScript package version and the application release are tracked separately.

Editorial conclusion

Adopt wger if you want your training log, body measurements and food diary on a server you administer, and if you are willing to run Postgres, Redis and a Celery worker alongside it. Skip it if you want a hosted service with no operational work, or if your tracking needs are limited to a phone app. Before committing, verify the current docker compose file in the wger-project/docker repository, check that the REST API scopes match what your client needs, and confirm the AGPL-3.0 network clause is acceptable for how you intend to expose the instance.

Frequently asked questions

Official sources

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