A Practical Judgment About Owning openGym
The central question about openGym is not whether a self-hosted fitness app can imitate a hosted one. It is whether the project’s promise of control remains meaningful when a person needs guided behavior, several devices, editable history, imports, backups, authentication, media, and optional AI. The answer supported by the design is conditional: openGym is a strong fit for people who value an inspectable, portable record and are willing to operate its boundaries. It is not a universal substitute for a hosted service, because the same ownership that creates control also creates work and trust decisions.
The Ownership Model Works as a Chain
openGym’s design makes sense when its parts are viewed as one chain rather than as isolated features. A person creates a routine and stores it in an owned profile. A device uses that intent to build a workout. The completed workout becomes historical evidence. Pure training logic derives the next prescription and progress views from that evidence. When another device changes the profile, a revision and merge process tries to preserve both the plan and the recorded events. When the person exports or shares data, the operation distinguishes history, future intent, full restoration, and media. When a provider or local LLM is enabled, the data path and action path are explicit rather than ambient.
The chain has a useful invariant: the durable record remains more authoritative than the interpretations built from it. A routine is not proof of a completed session. A next target is not proof of what happened last time. An estimated one-rep max is not a measured maximal lift. A recovery map is not a clinical diagnosis. An AI proposal is not an approved plan. A file reference is not the file itself. These distinctions are what allow the application to change a derived result without rewriting the user’s history to make the result look consistent.
The same invariant explains openGym’s conflict strategy. A phone’s completed workout and a laptop’s routine edit can both be preserved because they represent different kinds of change. The merged profile can then derive future behavior from the combined inputs. A stale target calculated before the merge does not need to win because it is an interpretation, not a new event. This is why synchronization cannot be judged only by whether it avoids duplicate requests. It must preserve the meanings that later calculations depend on.
It also explains the project’s portability boundaries. A workout-history import brings in events but does not silently replace future intent. A plan share carries reusable routines and scheduling but not the sender’s private history or media. A full backup can replace the destination because restoration has a different purpose. A media reference can travel without the binary, while a media-inclusive export carries both and therefore carries more privacy and storage responsibility. Ownership is preserved not by exporting everything indiscriminately, but by giving each kind of data an operation that matches its role.
The chain remains visible in the authentication model. A passkey proves access for a configured origin and hostname. A signed session carries the profile identity and can be revoked account-wide. Profile-scoped routes decide which state the identity may reach. The host operator still controls the files and backups. None of these controls replaces the others. A valid passkey does not protect an exposed backup; a private host does not make a forged browser request harmless; a profile boundary does not remove an authorized administrator’s documented access.
The same layered reasoning applies to AI. The Coach may receive a bounded projection after administrator configuration and profile consent. The MCP bridge may read a local projection without writing. A proposal can be validated, compared with the current plan, approved, applied, and reverted. The historical log stays outside the Coach’s change surface. The point is not that the model becomes trustworthy because it is wrapped in code. The point is that the model’s authority is limited by the same distinctions that govern storage and synchronization.
This makes openGym’s ownership thesis more precise than “your data is on your server.” The thesis is that the application tries to keep ownership legible as data moves through transformations.