Self-hostedHealth and Fitness

wger

Self-hosted health and fitness software.

wger is self-hostable software from the Awesome Selfhosted data index. Agents can inspect the source, deploy it in a controlled environment, and operate the browser UI; API or CLI support should be verified in project docs.

Agent access evidence

API

partial

Metadata suggests an API, server, integration, or automation surface; verify exact endpoints in project docs.

Evidence

Browser

strong

Self-hosted web app can be operated through a browser once deployed.

Evidence

Account creation

partial

No vendor signup is required for self-hosted use, but deployment, admin setup, and local auth configuration are usually required.

Evidence

Pricing clarity

strong

Self-hosted/open-source licensing makes software cost inspectable; infrastructure cost depends on deployment.

Evidence

Docs quality

partial

Project website or source repository is listed for documentation and deployment review.

Evidence

Sandbox

strong

Self-hosted deployment supports local, staging, or disposable test environments before production use.

Evidence

Readiness score

Usable

Usable: 64/100. Strongest in agent safety; weakest in machine operability.

Machine operability9/25

Agent safety20.4/25

Agent readability15/20

Auth and setup10.5/15

Production reliability8.8/15

Best for

Self-hosted health and fitness workflows, internal tools, and controlled deployment experiments.

Pricing

Self-hosted/open-source licensing listed as AGPL-3.0; infrastructure costs vary by deployment.

Auth

Auth and permissions depend on the deployed app configuration; platform metadata: Python, Docker. Source code: https://github.com/wger-project/wger

Account creation

No vendor signup is required for self-hosted use, but deployment and admin setup are required.

Browser support

Browser UI can be operated after deployment; exact flows depend on the app configuration.

Limitations

Key limitations: generated from community metadata, not a full security review. Verify maintenance activity, license, deployment docs, auth model, backup and restore path, update process, API or CLI support, and data exposure before production agent automation. API automation needs client-side throttling, idempotency where supported, pagination limits, retries, and audit logging. Browser automation can be brittle around UI changes, MFA, captchas, policy prompts, and hidden confirmation states.