SparkyFitness: a self-hosted household tracker with a non-commercial licence

The problem SparkyFitness is aimed at

Most consumer fitness tracking splits across subscriptions. The README's own comparison page argues that covering nutrition, strength, sleep, fasting, cycle and medication tracking means three or four separate subscriptions per person, and that even then no single report spans them. SparkyFitness answers that by putting the data in one server you run, with multiple user profiles and family access on top. The target user is a household rather than an individual. The README lists multiple user profiles and family access as a core feature and the comparison table claims seven granular permissions, which is a different design point from a single-account tracker that happens to support a second login. The secondary audience is anyone who wants the data to stay on their own infrastructure. The README states the project stores and manages health data on infrastructure you control, without relying on third party services, and self-hosted is the first topic on the repository.

What actually runs: server, web frontend, two mobile apps

The repository describes three components: a backend server that provides the API and data storage, a web-based frontend, and native mobile apps for iOS and Android. The primary language is TypeScript, which is consistent with a shared API and web layer, though the README does not break down which parts of the mobile apps are native versus shared. Data flow is pull-then-store. Integrations sync activity such as steps, workouts and sleep, plus health metrics like weight and body measurements, into your SparkyFitness server. That wording matters: the README's footnote states that sleep stages, HRV and blood glucose are imported from your watch, phone or meter, and that SparkyFitness stores, analyses and charts them rather than measuring them itself. So the server is a store and a reporting layer, not a sensor. The integration list is long and mixed in character: Apple Health and Google Health Connect for phone-collected data, Fitbit, Garmin Connect, Withings, Polar Flow, Oura and Strava for devices and services, OpenFoodFacts, USDA, Fatsecret, Nutritionix, Swiss Food Database, Mealie, Tandoor and Norish for food, and Wger and Free Exercise DB for exercises. Two entries carry caveats in the README itself: Strava is marked partially tested, and Yazio is noted as using an unofficial API. An unofficial API can break without notice, and the project is telling you so.

Getting a server up with Docker Compose

The README offers two installation paths and documents the self-hosted one first. The commands it gives are a folder creation followed by a compose file download: mkdir sparkyfitness && cd sparkyfitness, then a download step that the supplied README truncates mid-word. Because the excerpt cuts off at that point, the exact compose file URL and the service names are not something this article can state. What is confirmable is the shape: a Docker Compose deployment, which implies a compose file you fetch, environment values you set, and a persistent volume for the database. The README does not, in the material available, list the required environment variables, the default port, or the database engine. Treat those as things to read from the compose file itself before you start. The second path is not described in the excerpt either. On authentication, the core feature list names OIDC, TOTP, Passkey and MFA, so a self-hosted deployment can sit behind your existing identity provider rather than local passwords alone. That is the part of the setup worth planning before you invite family members, since permission scoping is claimed at seven levels and account creation order will affect who administers whom.

The licence is the first thing to read, not the last

The repository metadata reports the licence as NOASSERTION, and the README is unusually direct about why: SparkyFitness is source-available, not open source, the licence is non-commercial, and commercial use requires permission. That single sentence changes the adoption decision more than any feature on the list. If you are an individual running this for your household, the stated terms appear to cover you. If you are a company wanting to offer this to employees, a gym wanting to host it for members, or a developer wanting to build a paid product on the API, you are outside what the README describes and need to seek permission. This is not a legal opinion and the LICENSE file is the authority; the point is that the README's own framing contradicts the assumption many engineers make when they see a public repository with a Docker Compose file. The repository topics include self-hosted and selfhosted, which is a deployment property, not a licensing one. Do not read one as the other.

The AI features are beta, and the README says so

SparkyAI is described as an optional conversational interface for logging data and reviewing progress. The documented capabilities are logging food, exercise, body stats and steps through chat, uploading food images for automatic meal logging, and retaining conversation history for follow-ups. The README labels the whole set as beta, twice: once in the section heading and once in a note. It also advertises an MCP server and bring your own LLM, which means the model is your choice and presumably your API key and your cost. The honest reading is that chat-based logging is a convenience layer over the same database the manual entry path writes to, and that its reliability is not something the README makes any claim about. Image-based meal logging in particular depends on the model recognising the food and on a matching entry existing in whichever food database you have connected. If you are evaluating SparkyFitness for the AI, you are evaluating a beta feature whose accuracy the project does not quantify. If you are evaluating it for the tracking, the AI is a feature you can ignore, and the core feature list does not depend on it.

Where it fits badly, and what to use instead

SparkyFitness is the wrong tool if you want a permissively licensed codebase you can modify and redistribute, because the licence is non-commercial by the README's own description. It is also the wrong tool if you do not want to run a server. There is no hosted tier described in the material; the two installation paths are self-hosted variants, and the mobile apps are clients to your server. For the self-hosted strength-training case specifically, wger is the obvious alternative and the README's own table places it there: wger is marked as self-hosted with your data staying yours, and as not supporting wearable or health-platform sync, while SparkyFitness claims eight or more services. The difference in approach is scope. wger is a workout and gym management tool that grew a nutrition side; SparkyFitness is a general health record that includes strength work among nutrition, hydration, sleep, fasting, mood and body measurements. If your need is programming sets and tracking lifts, wger's narrower focus is a better match and its licence situation is different. If your need is one place where a family's food, weight, steps and sleep land together, the breadth is the reason to pick SparkyFitness. Note that the comparison table is written by the project being compared, and the README says so explicitly, so use it as a map of categories rather than as a verdict.

Upgrade cadence and what it costs you to stay current

The release history shows v1.6.2 on 14 August 2026, v1.6.4 on 27 August, and v1.6.5 on 7 September, with the last push to main on 10 September. Three releases in roughly three weeks is a fast cadence for a self-hosted service. That is good for fixes and bad for operators who dislike touching a working deployment. Because the documented install is Docker Compose, the upgrade path is presumably pulling a new image and restarting, but the README excerpt does not state a migration policy, whether database schema changes are applied automatically on startup, or whether downgrades are supported. Those are the questions to answer before you put family data in it. The comparison table claims CSV import and free data export, which is the mitigation: if you can export, a bad upgrade is recoverable rather than terminal. Verify that the export actually covers the tables you care about, and take one before the first upgrade rather than after. Running cost is your hardware, your electricity and, if you enable SparkyAI, your model provider's bill. There is no subscription described.

Editorial conclusion

Adopt SparkyFitness if you already run Docker Compose on hardware you control, want one database for a household, and can live with a licence that the README describes as non-commercial and requiring permission for commercial use. Do not adopt it if you need a permissive OSI licence, or if you want the software itself to measure sleep stages, HRV or blood glucose, since the README states those are imported from a watch, phone or meter and only stored and charted here. Before committing, verify the licence text in the LICENSE file against your intended use, confirm that your specific wearable appears in the integration list rather than relying on the count, and check whether the mobile apps are distributed through the app stores or built from the repository.

Official sources

1. CodeWithCJ/SparkyFitness on GitHub
2. Issues
3. Project website
4. README
5. Releases