B — Some risk signals Graded October 16, 2026Minor concerns worth a quick check.Based on public adoption and transparency signals as of October 16, 2026. Our opinion, not a code audit or security guarantee.

App connector · Data & databases, Files & documents

openGym

Self-hosted gym & body-weight tracker — plan routines, log workouts (supersets, warm-ups, cardio), see which muscles are trained, fatigued or detrained, import from FitNotes/Strong/Hevy, passkey login. Your data, your server.

Bottom line: Signal-based grade (4/7 points): very widely starred on GitHub, public source code. This reflects adoption and transparency, not a code audit.

Popularity score: 46/100
Rank: Not ranked: outside the 500 most popular tools
GitHub stars: 12.5k

What it does

openGym is a self-hosted fitness tracking application that lets you plan workout routines, log exercises (including supersets, warm-ups, and cardio), and monitor muscle fatigue and training status. It supports data imports from popular fitness apps like FitNotes, Strong, and Hevy, and uses passkey authentication to keep all your workout data on your own server.

Who it’s for

Fitness enthusiasts and builders who want complete control over their workout data and prefer self-hosted solutions over cloud-based fitness trackers. Teams or individuals integrating fitness tracking into broader AI agent workflows or personal health systems.

Copy-paste setup

Check these steps against the project’s own instructions before running anything.

Verify against the repo README for current instructions. Likely deployed as a self-hosted application (Docker or Node.js). For MCP connector use, check the GitHub repo for server configuration details and any Claude Desktop mcpServers JSON schema. Typical pattern:

json

{
  "mcpServers": {
    "openGym": {
      "command": "node",
      "args": ["/path/to/opengym/server.js"],
      "env": {"DATA_DIR": "/your/data/path"}
    }
  }
}

Always verify the official repository for exact setup steps.

Risks

Data exposure on self-hosted instance: Misconfigured firewall, reverse proxy, or TLS settings could expose sensitive health/workout data to the internet; ensure proper access controls.
Passkey implementation security: Depends on correct implementation of WebAuthn/passkey storage and validation; audit the authentication code or verify it uses battle-tested libraries.
Import data integrity: Importing from third-party fitness apps (FitNotes, Strong, Hevy) requires parsing untrusted data; validate import logic against injection attacks.
Maintenance and supply-chain risk: Low weekly npm downloads and unclear maintenance cadence suggest slower security updates; monitor for unpatched vulnerabilities.
Local database security: Unencrypted workout database on disk could expose sensitive data if the server is compromised; consider disk-level encryption.

How to stay secure

Hardening Guide: openGym MCP Connector

Least-privilege permissions

Restrict user access by role: Only give admin/setup privileges to people who need them; regular users should only see their own workout data, not other people's.
Limit database access: If your database needs to talk to other systems, use read-only credentials where possible (a system that can only read data can't delete or steal it).
Audit import permissions: Only allow workout data imports from accounts that should have that ability; don't let every user bulk-upload data from external fitness apps.

Network isolation

Firewall your server: Block all internet traffic except what's necessary (typically HTTPS port 443); if openGym is only for internal use, restrict it to your office network only.
Use a reverse proxy with TLS: Place a security layer (like Nginx or Caddy) in front of openGym; force all connections to use encryption (HTTPS) so workout data can't be read in transit.
Encrypt the database at rest: Enable disk encryption on the server storing workout logs so that if someone physically accesses or hacks the machine, they can't read unencrypted health data.

Monitoring

Check logs weekly: Review access logs for unusual login patterns, failed authentication attempts, or users accessing others' data.
Track dependency updates: Subscribe to security alerts for npm packages that openGym depends on (since the project has low weekly downloads, updates may be infrequent); patch known vulnerabilities promptly.
Monitor import activity: Log which files are being imported and from whom; watch for suspicious bulk uploads or repeated failed imports that could indicate injection attacks.

Red flags to watch for

Passkey login fails unexpectedly: If your WebAuthn/passkey authentication suddenly breaks or behaves oddly, audit the implementation before users are locked out or security is bypassed.
Unencrypted traffic warnings: If your browser shows "Not Secure" or HTTPS warnings when accessing openGym, stop using it until TLS is fixed.
Import errors with cryptic messages: If data imports crash or behave strangely when importing from FitNotes, Strong, or Hevy, do not retry; investigate the import code first to rule out injection exploits.
Long gaps without updates: If openGym goes more than 3–6 months without security patches or dependency updates, contact the maintainer or consider alternatives.

Alternatives

MyFitnessPal / Cronometer — cloud-hosted, feature-rich, but user data held by vendor.
FitBod — AI-powered workout suggestions with cloud sync; proprietary algorithm.
Hevy — modern UI, social features, import/export available; cloud-first.
Self-hosted Nextcloud + FitTrackee — lightweight, privacy-focused, community-maintained alternatives.

Sources

github.com/DuarteSantos8/openGym