Open Wearables: A Self-Hosted Wearable Data Aggregator With an AI Layer That Is Not Finished

The Integration Tax Open Wearables Is Trying to Remove

Every wearable vendor ships its own OAuth flow, its own units, and its own idea of what a sleep session looks like. A product that supports Garmin, Whoop and Apple Health ends up maintaining three sync paths, three token refresh routines, and three data mappers. The README states the problem directly: building a health app that supports multiple wearables typically requires significant development effort per provider to implement OAuth flows, data mapping, and sync logic. Open Wearables exists to absorb that work behind one API and one normalized data model.

The intended audience is split. The first group is developers building fitness coaching, healthcare, wellness or research products that aggregate device data. The second group is individuals self-hosting the platform for their own wearables, which the README calls out under an important note: your data stays on your own infrastructure. Those two audiences want different things from the same codebase, and that tension shows up later in the setup instructions.

Where the Data Actually Flows

The repository is a two-part application. The backend is Python on FastAPI, and the frontend is React with Tanstack, per the README badge. The developer portal runs on port 3000 and the API with its Swagger UI runs on port 8000, which tells you the two processes are separate and the portal is a client of the API rather than the API itself.

Data enters through provider connections. Each user is a record inside the platform, and the README describes adding users either through the portal or through the API, with connection links that can be shared (the fitness coaching example mentions sending one over WhatsApp). Once a device is connected, the platform normalizes metrics such as heart rate, sleep, activity and steps into a common shape. The portal then surfaces per-user details: connected sources, integration status, and metrics with visualizations, plus aggregate counts of users and data points.

Notifications are meant to leave the system through webhooks. The automations section describes defining conditions in natural language and pointing a backend endpoint at the platform to receive health insights in real time. That is the intended architecture, but the section is labeled coming soon, so the ingestion and normalization path is the part you can rely on today.

Getting It Running: Docker Compose, Two Env Files, One Password Trap

The documented path is short. Clone the repository, then copy two environment files:

cp ./backend/config/.env.example ./backend/config/.env cp ./frontend/.env.example ./frontend/.env

Then start the stack with docker compose up -d. The README claims no third-party dependencies for core functionality, meaning the whole thing runs locally. For a setup without Docker, the docs link to a local development page rather than repeating the steps in the README, so plan on reading that page if you want to run the backend and frontend as separate dev processes.

The login step is where the first real operational detail lives. An admin account is created on startup from ADMIN_EMAIL and ADMIN_PASSWORD, with documented defaults of admin@admin.com and your-secure-password. The seed runs only while the developer table is empty. Once any developer account exists, it is skipped, so changing ADMIN_PASSWORD later does not update the existing account. The README's instruction is to change the default password from the developer portal right after first login, and to invite further accounts from the portal. If you deploy with the defaults and never log in, you have an admin account with a published password.

Optional sample data comes from make seed, which creates test users and sample activity data. API keys are generated in the Credentials tab of the portal. Interactive API documentation is at http://localhost:8000/docs.

The AI Health Assistant Is a Roadmap Item, Not a Feature

The project description leads with AI-ready language, and the repository topics include healthcare-ai. Read the README carefully and the AI surface narrows considerably. Health Insights and Automations is marked coming soon, as are the embeddable widgets. The individual-user note says to stay tuned for upcoming features like the AI Health Assistant and personal health insights automations.

What the README does describe is a design sketch: natural language conditions for when notifications should fire, webhook notifications to your own endpoint, dry runs against historical data, and a human-in-the-loop step where incorrect AI interpretations are marked during testing. That last item is the most interesting part, because it admits the interpretation layer will be wrong sometimes and builds a correction path into the product rather than pretending otherwise. But none of it is described as shipped, so anyone evaluating Open Wearables for an AI feature should treat this as a plan with a stated interface, not working software.

The release history is consistent with a project still filling in provider coverage. 0.7.0 is titled Google Health API and SensorBio, 0.6.3 covers nap detection and HTTP logs middleware, and 0.6.2 is simply Data integrity. Provider breadth and data correctness are the active work, not the AI layer.

What You Give Up Compared With a Hosted Aggregator

The obvious alternative is a hosted wearable data aggregator, the kind of service where you sign up, drop in a client ID, and get a normalized API plus a managed OAuth flow for consumer-facing apps. The difference in approach is who runs the token exchange and who holds the data. A hosted aggregator handles provider credentials for you, which matters when your end users are consumers who will not install your server, and it usually carries a per-user price.

Open Wearables inverts that. You run the infrastructure, you hold the tokens, and you pay in operational time instead of subscription fees. The README frames this as privacy and control, and for an individual self-hosting their own Garmin data that framing is accurate. For a company, the trade is less clean: you now own the upgrade path, the database, and the provider breakage when a vendor changes an endpoint. Nothing in the supplied material describes a hosted or managed offering from this project, so the self-hosted model is the only model.

A second alternative is writing the integrations yourself. That is the baseline the project is arguing against, and the argument is reasonable if you need three or more providers. If you need exactly one provider and no normalization, the platform adds a database, a portal, and a deployment to maintain for very little return.

Licence, Maintenance, and What You Inherit

The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice and permission notice preserved. That is permissive enough for a product you intend to sell, though the usual caveat applies: the software ships without warranty, and you are responsible for how you handle health data under whatever privacy regime applies to you. This is not legal advice, and health data specifically tends to attract rules beyond the software licence.

Maintenance cost is the real number to estimate. The last push recorded for the repository is 2026-09-10, and the three most recent releases span June to August 2026, so the project is active. Active also means the schema and API surface can move. Upgrading a self-hosted instance means reading release notes for changes like the nap detection in 0.6.3 or the data integrity work in 0.6.2, and re-running migrations against your own database. If you fork the backend for custom provider logic, every upstream release becomes a merge.

The upgrade path is Docker Compose, which keeps the mechanics simple, but the environment file split between backend/config/.env and frontend/.env means configuration drift is easy to introduce across environments. Treat both files as deployment artifacts, not local scratch files.

Who Should Adopt It, and What to Verify First

Adopt it if you are building a product that needs data from several wearables and you are comfortable running Postgres-era infrastructure yourself, or if you are an individual who wants your own device data on your own machine. The documented Docker path is genuinely short, and the developer portal gives you API key management and user management without writing an admin UI.

Do not adopt it if your product depends on the AI Health Assistant, natural language automations, or embeddable widgets, because the README marks all three as coming soon. Do not adopt it if your users are consumers who expect to connect a device through a flow you do not operate, since the supplied material describes self-hosting as the only deployment model. And do not adopt it if you need one provider only and no cross-device normalization.

Three things to verify before you commit. First, open docs.openwearables.io and check the current provider list against your target devices, because the README names Garmin, Whoop and Apple Health as examples rather than as a complete supported set. Second, confirm what the Google Health API support added in 0.7.0 actually covers, since the release title names the integration but not its scope. Third, decide your admin bootstrap procedure before the first deploy, because the seed only runs against an empty developer table and will not correct a default password you left in place.

Editorial conclusion

Adopt Open Wearables if you want wearable data on your own infrastructure and are willing to treat the AI automations and embeddable widgets as unshipped. Do not adopt it if your product depends on those features today, or if you need a managed OAuth flow for consumer sign-in. Before committing, check the provider list on docs.openwearables.io against your target devices, confirm whether the Google Health API support in 0.7.0 covers the scopes you need, and rotate ADMIN_PASSWORD from the developer portal on first login, because the seed only runs while the developer table is empty and will not update an existing account afterwards.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. the-momentum/open-wearables on GitHub