One server combines food, workouts, sleep, and family records
SparkyFitness is unusually broad for a self-hosted tracker. One account records meals, exercise, hydration, fasting, medication, sleep, and body measurements. Web, iOS, and Android clients point to your server. Family access adds profiles and permissions. That scope is the product's best argument and its largest testing surface.
The server can import from Apple Health, Google Health Connect, Fitbit, Garmin, Withings, Polar, Oura, Hevy, and several food databases. The README carefully says it stores and charts watch data such as sleep stages and blood glucose instead of measuring those values itself. Optional SparkyAI can log meals or exercise through chat and inspect progress, but the project marks that assistant as beta.
An MCP server gives compatible clients another route into the system with a model chosen by the operator. That suits people who already host personal AI tools. It also turns authentication and tool permissions into health-data controls. A conversational interface should not get broader write access than the person using it, especially on an instance shared by several family members.
The license excludes commercial use without written permission
SparkyFitness does not call itself open source. Its custom license allows personal, educational, and nonprofit use only when those activities do not generate revenue. Commercial use requires prior written permission from the author. Modified versions inherit the same non-commercial terms unless the author approves something else, and contributors assign their interest in submitted work to the original author.
That rules out more cases than a casual GitHub visitor may expect. A paid coach, employer wellness portal, subscription service, or commercial appliance cannot rely on the public repository alone for permission. The restriction may be fine for a family's private server, but it is incompatible with teams that require an OSI-approved license or the right to build a business without a separate agreement. Check licensing before evaluating the deployment.
What happened when we ran it
Our sandbox installed commit 619bf54 with pnpm in 381 seconds. The install pulled 2,816 packages and consumed 3,308 MB on disk. That is the heaviest dependency result in this review batch by a wide margin. The checkout before dependencies was 39.7 MB, yet it contained 3,714 files and about 771,406 lines of source across its workspaces.
The root package offered no build script or target that our harness could run, so the build step was skipped. It also exposed no test script or target, so tests were skipped. We found 21 CI workflow files, no root tests directory, and no Dockerfile in the measured repository. Those signals suggest package-specific checks live behind the monorepo's own development workflow, which a contributor needs to learn before treating the root install as validation.
The successful install proves that dependencies resolved in our 3-CPU, 8 GB Debian container. It does not prove the frontend, server, mobile clients, database migrations, or provider syncs work together. With no build and test targets available to the harness, our run produced no compiled artifact and no passing test count. The right takeaway is an expensive bootstrap with verification still outstanding.
Docker Compose runs three required services from published images
Deployment is shorter than source setup. The README downloads a production Compose file plus an environment template, then starts 3 services: PostgreSQL, the application server, and an Nginx frontend. The browser reaches the frontend on port 8080 in the quick example. The Compose file waits for PostgreSQL health before starting the server's migrations.
Do not run the example secrets unchanged. The environment file includes database credentials, a 64-character key for encrypting API credentials, and a Better Auth secret used for sessions and two-factor data. Changing the encryption key invalidates stored external data-source credentials. Changing the authentication secret after TOTP enrollment can lock users out. The public frontend URL and proxy-hop settings also need to match the real HTTPS route.
Backups are part of setup because this is personal history, not disposable app state. The release notes tell users to back up both the database and environment before upgrading. Uploaded images and server backups live on separate mounted paths, while PostgreSQL has its own persistent volume. Test a full restore on a spare instance before upgrading.
Health imports can preserve a workout while losing its detail
Issue 2456 describes a Health Connect resync that kept distance, duration, and pace but replaced the parent workout row and dropped associated GPS points and laps. The map initially appeared, then vanished after another sync. That v1.6.4 report concerns one import path, so test before-and-after exports for your provider.
Other integration gaps affect what users see rather than what is stored. Issue 2471 reports Polar sleep and activity data importing while daily steps, heart rate, and calories remain absent from reports in v1.7.0. Issue 2269 says the workout rest timer can show a notification without sound when the iOS app is backgrounded. The open threads and active fixes are healthy community signals, but the affected records and alarms are exactly why broad health integration needs narrow acceptance tests.
Version 1.7.1 is active and still carries beta warnings
GitHub recorded the last push on September 15, 2026, one day after v1.7.1 was released. The repository had 5,960 stars and 151 combined open issues and pull requests when fetched. The latest release fixes authentication migration ordering. Frequent releases and 21 CI workflows show active maintenance, while the queue also reflects how many web, mobile, provider, and database paths are changing.
The README warns that breaking changes may occur, advises against automatic container updates, and labels the AI assistant, family access, and API documentation as beta. Pin releases, read upgrade notes, keep tested backups, and trial changes against copied data. SparkyFitness earns the work when its broad household record replaces several apps. The non-commercial license and integration-specific failures remain firm reasons to choose a narrower tracker.