openGym is already a serious lifting app, not a dashboard shell
openGym covers the work a regular lifter repeats every week: plan routines, start the scheduled session, log warm-ups and working sets, time rests, track body weight, and review progression. Its library lists 1,324 exercises, and the interface is translated into 14 languages. This is much closer to a finished daily tool than a CRUD exercise log.
The strongest design choice is local ownership. A self-hosted instance stores profiles and workout state under ./data, while passkey private keys stay on the user's device or password manager. There is no subscription or telemetry in the core product. That makes openGym attractive to someone who wants phone convenience without handing years of training history to a fitness startup.
What happened when we ran it
Our sandbox cloned commit f91cde1 and ran npm at the repository root. Installation finished in 3 seconds, adding 2 packages and occupying 1 MB. npm audit found 0 known vulnerabilities. The 19.6 MB checkout held 555 files and about 69,530 lines of source, with 4 CI workflow files and a Compose file. The scan found no Dockerfile and no central tests directory.
There was no root build script or target, so our build step was skipped. The same was true for tests: no root test script or target meant the test step was skipped. The README says front-end tests live beside pure helper functions and run from frontend/, while normal deployment builds inside containers. Our successful root install exercised neither path and should not be read as an application pass.
Docker Compose is short, while public access adds real configuration
The documented server path is four commands: clone the repository, copy .env.example, pull the images, and start Docker Compose. The web UI then listens on port 8080 and proxies its API on the same origin. Prebuilt images exist for amd64 and arm64, and users can replace the pull with a local Compose build.
Passkeys make the public setup less forgiving. RP_ID must match the hostname, and ORIGIN must match the complete URL. Internet access from a phone requires HTTPS. The README says many login problems come from those two settings. Backups are easy to understand but still your job: db.json, each user's state file, the audit log, and the session secret all sit inside ./data. Losing that directory means losing the server record.
JSON storage keeps ownership visible, and issue 283 exposes its sharp edge
Each profile's plan, sessions, weight history, and settings are held in a JSON state file. That avoids a database service and makes a small household instance easy to inspect or move. It also means synchronization deserves close attention. The app supports several devices, revisions, and merging, so the storage format may be simple while the behavior around concurrent copies is not.
Open issue 283 documents a v1.3.8 case where two tabs share a revision marker but keep separate in-memory state. According to the report, a stale tab can submit its old state with the newer shared revision and replace a workout logged in the other tab. Our lab did not run the app. Until the issue is closed and released, avoid parallel tabs and keep frequent exports or snapshots.
The 140 MB exercise-media download carries a licensing warning
The first launch obtains about 140 MB of exercise images and animations from an upstream dataset. openGym does not bundle that media in its repository. The README says the metadata and instructions are MIT-licensed, but the visual files sit outside both that license and openGym's AGPL. It also says ownership is disputed between two named sources. Anyone redistributing or reusing the media commercially needs clearance from the rights holder.
The application code itself uses AGPL-3.0. You can host and modify it, but a modified network service must offer its corresponding source under that license. The standalone Android APK keeps data on the phone and needs no server. iPhone users get a PWA from their self-hosted instance or must build the native app with Xcode, since the project provides no iOS download.
v1.3.8 shows fast maintenance and an equally fast-moving product
GitHub recorded the last push on September 20, 2026, followed by the v1.3.8 release that day. The repository had 1,184 stars and 121 combined issues and pull requests when fetched. Open issues were still being updated on September 22, including the stale-tab data-loss report, offline exercise media, progression behavior, and requests around trainers and plan exports.
The v1.3.8 notes say 24 reports were closed and 11 community pull requests from 6 contributors landed. Fixes included iPhone keyboard behavior, notifications firing while disabled, narrow-screen number fields, and assisted-exercise progression. The detail inspires more confidence than a generic changelog. It also shows how many phone, sync, and training-rule edge cases appear once people depend on the app during real sessions.
Choose it for lifting depth, then operate it like personal data
openGym fits a lifter who values detailed session behavior and wants control of the server. Docker reduces the initial work, and the current app has enough training logic to replace a paid tracker rather than merely record sets. The optional read-only MCP server and approval-based AI coach stay separate from the basic deployment.
The decision turns on operational habits. Use HTTPS, verify the passkey origin, back up ./data, and treat the exercise media as third-party material. Most of all, watch issue 283 before relying on several tabs for the same profile. wger is broader for nutrition, while Workout.cool and SparkyFitness suit coaching or household health tracking.