Wearable health data on your infrastructure.
Connect the wearables your users already own, normalize the data, and compute health scores, with nobody else keeping a copy. Open source and MIT licensed.
$ git clone https://github.com/the-momentum/open-wearables.git
$ cd open-wearables
$ cp ./backend/config/.env.example ./backend/config/.env
$ docker compose up -d
# Running on your own machine, in your own region
$ curl localhost:8000/
{"message": "Server is running!"}
What is a self-hosted
wearable health platform?
Everything between a wearable and an intelligent recommendation, running inside your own environment instead of a vendor's cloud.
Open Wearables
normalize · deduplicate · score
Your product
API · dashboard · AI features
Nothing leaves this boundary.
Wearable data
One integration through provider OAuth, normalized into a single schema and deduplicated across overlapping sources.
Health scores
Sleep and resilience computed from the underlying data, with the logic in the repository rather than behind an API.
AI reasoning
An MCP server gives any LLM structured access to health data along with a reasoning framework, not a raw data dump.
Deployed where you need it
Official Docker images on AWS, GCP, Azure, or your own data center, in the region your obligations require.
How many companies touch your users' health data?
Every health data architecture has an answer to this question. Most teams have never counted.
The provider
Garmin, Whoop, Apple. Unavoidable either way, the data originates there.
The aggregator
Health data lands in their cloud first. Now a data processor in your compliance chain.
Their subprocessors
Whoever they build on. Their regions, their security posture, their roadmap.
You
Last in line for data your users trusted to you.
Every DPA, BAA, security questionnaire, and subprocessor notification has to account for parties two and three.
Nothing to inherit, nothing to notify, nothing to audit but your own stack.
Answered by architecture, not by assurances.
For some health products the hosting question is already settled, by a customer's legal team or by a certification the company holds. These are the situations where it comes up.
Health data hosting standards
Some markets certify who may host health data and under what conditions. Routing patient data through a third-party service abroad tends to break that commitment.
Hospital and clinical procurement
When procurement runs through legal, security, and group-level sign-off, data location lands in the requirements before any technical evaluation. A cloud-only vendor rarely reaches the demo.
Operating across jurisdictions
A product live in several countries picks up every market's rules at once. GDPR treats health data as a special category, and non-EU markets add their own.
Enterprise security review
Insurers and large employers ask where data sits, who has access, and which subprocessors are in the chain. A much shorter conversation with no third-party processor to describe.
If any of these look familiar, the question is not whether to self-host. It is what the deployment needs to hold up under an actual review.
Map it with usControls you can point at during a review.
Concrete mechanisms, not assurances. Each one is something your team can demonstrate.
DELETE /api/v1/users/{id}/connections/garmin/data
# deletes that provider's data and revokes the connection
GET /api/v1/users/{id}/data-sources
{ "provider": "apple", "source": "HealthKit",
"device_model": "iPhone 14" }
OAuth tokens on your infrastructure
Provider credentials sit in your own database, on your own servers. No third party holds credentials for your users.
Per-provider data deletion
One endpoint deletes all of a user's data for a provider and revokes that connection in the same call.
Data provenance
A data sources endpoint reports where each of a user's data points came from, for the auditor who asks.
Deployment you control
Official Docker images for backend and frontend, deployed with Docker Compose in the region you choose.
Who is accountable
for the answer.
With a SaaS aggregator, that vendor's infrastructure and subprocessors become part of your compliance posture. With a self-hosted layer, your obligations run between you and your users.
SaaS: Cloud only, vendor's regions
Open Wearables: Self-hosted, in the region you choose
SaaS: Vendor plus their subprocessors
Open Wearables: None added
SaaS: Proprietary, black box
Open Wearables: Open, auditable, tunable
SaaS: DPA with the vendor required
Open Wearables: You control residency and processing
SaaS: BAA with the vendor required
Open Wearables: Your controls, BAAs via Momentum
SaaS: Cost tracks your user count
Open Wearables: Cost tracks the infrastructure you run
Independent proof, not a vendor reference.
Heart Monitor runs Open Wearables self-hosted in production, with all user health data on their own infrastructure. They adopted the open-source project and built the integration with their own team.
90k+
active users
~1 week
integration time
6
providers connected
Built and maintained by Momentum
Community support runs through Discord and GitHub Issues. When the compliance program on top of the infrastructure is the part you need help with, that is a services engagement, and BAAs are available for HIPAA-covered entities.
130+
engineers
220+
health tech projects
12
years in healthtech
Somebody is going to ask where your health data runs.
Better to have the answer before procurement, a regulator, or a customer's legal team asks for it.
Questions about self-hosting
It means the platform runs on infrastructure you control: your own cloud account or data center, in whichever region your obligations require. You deploy official Docker images for the backend and frontend, then point them at your own database.
Wearable health data travels from the provider into your systems with no third-party API storing it along the way, so no external processor holds your users' health data or their provider credentials. Because the platform is MIT licensed, the integration code and the scoring logic are readable and tunable by your own team.
No. HIPAA compliance comes from a program of safeguards: access controls, encryption, audit logging, breach response, and staff training, all of which have to be built and documented regardless of where the infrastructure runs.
Self-hosting makes several of those easier to implement correctly because you control the full stack. Momentum offers BAAs and the compliance work itself as a services engagement.
It settles the physical location question, provided you deploy in the region your obligations require.
GDPR also requires a documented legal basis for processing, defined retention periods, and mechanisms for rights like access and deletion. Residency is one requirement among several, not the whole picture.
You operate FastAPI, PostgreSQL, Redis, and Celery, which means infrastructure, monitoring, backups, and upgrades are yours.
For a team with a backend engineer, initial setup takes under a day and ongoing maintenance is low. For a team without that capacity it is a real cost, and Momentum offers a managed deployment on your own infrastructure as an alternative.
Yes, and it can run in parallel rather than as a forced cutover. The technical work is typically a few days.
The variable is user re-authentication: provider OAuth tokens held by your previous vendor cannot be transferred, so users reconnect their devices. Health data already in your own database does not need to be re-fetched.