Self-Hosted Wearable Data Platform

Health & Fitness

A wearable data platform: it puts data from different wearable devices (heart rate, sleep, steps, workout records and so on) into one format, serves it through a web developer portal and an API, and can generate sample data. You bring it up on your own machine with Docker Compose, the admin password is generated at random by a script, and anonymous usage statistics and error reporting are off by default. Derived from a frozen snapshot of an open-source project under the MIT licence; the delivery adds an orchestration file that builds the backend and frontend images from source, a script that generates the keys and password, and a quick-start guide in Traditional Chinese.

Subscribe & download See how to start

SubscriptionUS$49 per month

Last run2026-11-02

In practice

Readiness4 / 5

What you need

Few changes needed4 / 5

Who it is for

Developers and small teams who want data from different wearable devices in one place they control, taken through an API.

How to start

$ sh scripts/quickstart/init-env.sh
$ docker compose up -d --build

Browse the files

Files in the product repository at the pinned commit. A few house files are left out of the zip.

File overview1,546 paths

▸backend850

.copier-answers.yml
.dockerignore
.python-version
AGENTS.md
Dockerfile
README.md
alembic.ini
app/
config/
migrations/
…

▸contributing6

adding-providers.md
developing.md
issues.md
linting.md
pull-requests.md
testing.md

▸docs101

.nvmrc
LICENSE
README.md
api-reference/
app/
architecture/
coverage.css
deployment/
dev-guides/
developer-portal/
…

▸extensions1

.gitkeep

▸frontend524

.dockerignore
.env.example
.gitignore
.npmrc
.prettierignore
.vscode/
AGENTS.md
Dockerfile
Dockerfile.dev
README.md
…

▸mcp24

.python-version
README.md
app/
config/
pyproject.toml
tests/
uv.lock

▸scripts1

quickstart/

▫AGENTS.md

▫ATTRIBUTION.md

▫CLAUDE.md

▫CONTRIBUTING.md

▫GEMINI.md

▫LICENSE

▫LICENSE-99LL.md

▫Makefile

▫PRODUCT.md

▫QUICKSTART.md

▫README.md

▫SECURITY.md

▫SECURITY.upstream.md

▫delivery-manifest.txt

▫docker-compose.yml

▫Config and hidden files 24

Latest passing run

Clone → Checkout → Toolchain → Build images → Portal login and api key

Pre-purchase Disclosure

What you are buying

A self-hosted wearable data platform: it puts data from different wearable devices into one format, served through a web portal and an API, and can generate sample data. You bring it up with Docker Compose.

Derived from an open-source project under the MIT licence, and not the original project itself. Our work: an orchestration file that builds the images from source, a password generation script and a quick-start guide in Traditional Chinese.

Delivery is a frozen snapshot: one zip, taken from the product repository at revision 4f56076.

Known limitations

The interface is in English
The service serves plain HTTP on ports 3000 and 8000 of the local machine; TLS and a reverse proxy are yours to bring
Connecting a wearable vendor needs your own developer account and credentials, and none is preset in the delivery
Connecting Oura needs a public HTTPS address of your own as the authorisation callback address
Live Apple Health sync needs a mobile app developed separately, and is not in the delivery
Apple Health export files are best kept under 10 MB, and the object storage that chunked upload needs is not included
It stores personal health data, is not a medical device, and makes no health interpretation
The sleep and recovery scores the platform computes itself are off by default
Anonymous usage statistics, error reporting and outgoing webhooks are off by default
Upstream’s API is not yet settled and may change later
The admin password is applied only at the first start, and the value in .env is not synchronised afterwards
The data lives in Docker named volumes, and docker compose down -v deletes all of it
The first start builds the backend and frontend images from source, fetching from registries, apt and package repositories during that time
Pinned to the delivered snapshot; it does not follow upstream.

The liability cap, the scope of what is promised and the statutory floor are governed by the Terms of Service.

Vetting record

Everything below was checked against the pinned commit f067907. Every verdict carries its full reasoning, an evidence link and the checker; failures are published, not hidden — do not take our word for it, verify it yourself.

5 PASS0 WARN0 FAIL

Source ReviewPASS

Execution surface of the delivery reviewed item by item. Our own additions were read line by line: docker-compose.yml (only the frontend and API ports are bound to 127.0.0.1, and the other services such as the database, cache and webhook service open no port; it refuses to start when any key, the database password or the admin password is missing; anonymous usage statistics, error reporting and outgoing webhooks are off by default; the database and cache use named volumes) and scripts/quickstart/init-env.sh (openssl generates random values, .env is mode 600, an existing .env is not overwritten, and the administrator email accepts only letters, digits and . _ + @ -). The backend and frontend Dockerfiles are upstream’s own files with only the base images pinned by digest, and were also read line by line. The upstream Python and front-end sources were not read file by file; the basis is the MIT licence and container isolation.

Script SafetyPASS

The scripts on the buyer’s delivery path were each inspected: init-env.sh is ours (read line by line); the build goes through backend/Dockerfile and frontend/Dockerfile (read line by line: Python packages installed from uv.lock with --locked, the frontend installed from bun.lock with --frozen-lockfile, system packages from apt; the backend Dockerfile copies the tool programs from uv’s floating tag and upgrades pyopenssl to the latest version of the day during the build, with no download piped straight into a shell); the container start goes through upstream’s start scripts under backend/scripts/start/ (upstream’s own files, not read line by line).

RecencyPASS

This product is a frozen snapshot and does not follow upstream: the upstream source is pinned to the main-line revision taken on the day the product repository was created (see the evidence link), and the product repository is that snapshot plus our own commits.

LicensePASS

SPDX:LicenseRef-99LL-Product

Upstream LICENSE was checked word for word (the evidence link points at the file itself at the pinned version and matches the copy inside the product repository): the standard MIT text, copyright holder Momentum. It allows commercial use, modification, derivative works, redistribution and sale; the duty is to keep the copyright notice and licence text (LICENSE and ATTRIBUTION.md ship in the zip); upstream has no NOTICE file. The decision does not rest on GitHub’s licence field. For the product as a whole the 99LL product licence template is attached: upstream’s LICENSE is kept as it is and LICENSE-99LL.md is added as the sale and liability terms for the part we built, with spdx recorded as LicenseRef-99LL-Product.

Dependency LicensesPASS

This records the declared side, not a scan result: the Python dependencies are declared in pyproject.toml and locked by uv.lock, the frontend is declared in package.json and locked by bun.lock, and the packages themselves are fetched from their own repositories when the buyer builds; the database, cache and webhook service use third-party images at fixed versions, and the base images and system packages come from a registry and apt. The cache service is Valkey in place of the redis:8 used by upstream’s orchestration file. The licences of these dependency trees and images were not scanned item by item. Upstream has no submodule and no third-party dataset was copied in (see ATTRIBUTION.md).