WHOOP 4.0 is the only supported device
Life connects directly to a WHOOP 4.0 strap over Bluetooth Low Energy and keeps the official account out of the path. The iPhone saves readings before acknowledging them to the strap, then uploads batches to a private backend. That server archives original packets before acknowledging the phone. Prometheus export happens later, so a temporary monitoring failure does not have to erase the underlying capture.
The scope is narrower than the official app. Live heart rate, battery, wrist temperature, private dashboards, and some history handling are available. HRV and blood oxygen are partial, respiratory rate is experimental, and sleep entry is manual. Recovery, stress, steps, calories, workout detection, sleep stages, and the haptic alarm are absent. Life's strain score is its own 0 to 21 cardiovascular calculation, not WHOOP's proprietary score.
The firmware target is Harvard 41.17.4.0
Temperature, oxygen, and pulse-interval interpretations target WHOOP 4.0 firmware Harvard 41.17.4.0. The project archives unknown fields instead of promoting them to health metrics, which is the right bias for reverse-engineered sensor data. A device-calculated oxygen result can be withheld when it is missing, erroneous, or ambiguous. Wrist temperature is explicitly described as wrist temperature, not core body temperature.
The validation document draws an important line: software checks do not establish clinical accuracy. HRV has no ECG comparison, while respiration and SpO2 lack independent reference validation. iOS background execution can also interrupt collection. Life has recovery logic and durable buffers, but the README does not promise uninterrupted Bluetooth service. Anyone using these readings for medical decisions would be asking the software to support a claim its author rejects.
What happened when we ran it
Our run focused on the Python project under backend/ at commit 60e705a. In a fresh Debian container with 3 CPUs and 8 GB of RAM, 51 packages installed in 31 seconds and occupied 53 MB. The build completed in 8 seconds. The full repository was 2.4 MB, with 113 files and roughly 8,578 lines of source.
Pytest ran for 208 seconds and did not finish cleanly. The supplied summary reported 102 passed, 1 skipped, 0 failed assertions, and 1 collection/setup error in the 103-test run. tests/test_wire.py stopped on ModuleNotFoundError: No module named 'google' while importing Protobuf modules. The log does not say why that module was absent, so we cannot label it a packaging bug or a system-package problem.
Pip-audit reported 0 known vulnerabilities in the installed Python environment. The repository has a Dockerfile and a tests directory, but no CI workflow files. Our test method covered the backend build and Python suite. It did not compile the Swift client, connect to a WHOOP strap, exercise Tailscale, start the complete Compose stack, or compare physiological readings with reference hardware.
Six backend services turn ownership into maintenance
The documented server path starts an API, a remote-write worker, scheduled analysis, Prometheus, Grafana, and a gateway. That is 6 named components to operate, even though Docker Compose groups them into one command. Tailscale Serve publishes the gateway privately. The ingestion token and Grafana administrator password live in files mounted as Docker secrets, while machine settings remain in .env.
The operations guide is unusually candid about the remaining chores. Backups include credentials and personal telemetry, so an off-machine copy needs protection. Automatic off-PC backup is not configured. Raw archives and phone records have no automatic pruning, and the operator must watch disk use. Prometheus has 5 alert rules, but there is no external notification destination. Data ownership here means owning the pager too.
iOS 17 and personal signing are mandatory
The phone client needs iOS 17 or later, full Xcode, XcodeGen, Developer Mode, a bundle identifier, and an Apple signing team. Personal Team provisioning expires, so reinstalling updates remains subject to Apple's trust and device-pairing rules. The same bundle identifier must be kept across updates to preserve local data. Force-quitting the app also affects background collection until it is reopened.
Those requirements make Life a personal engineering project rather than an App Store product. The architecture protects against several ordinary failures by keeping data on the strap, in phone SQLite, and in the backend archive. It still cannot reconstruct readings the strap never stored. Reboot, first-unlock, long overnight use, and replacement-server recovery are described as separate operator tests rather than guaranteed behaviors.
No root license means no open-source grant
GitHub detected no license, and the project's own public-release checklist says Life has no root license. It explicitly warns that a public repository does not grant an open-source license. That blocks reuse, modification, and redistribution for any team that needs clear legal permission. A protocol reference retained under MIT does not license the rest of the code.
The repository was created on September 14, 2026, pushed on September 15, and had 141 stars on October 4. GitHub listed 0 open issues and 0 open pull requests, and there was no published release. Those facts describe a young public snapshot with little visible collaboration history. They do not prove abandonment, but they give a cautious adopter almost no release or community record to evaluate.
This is a careful research rig, not a finished health product
Life earns attention for preserving raw packets, documenting unknowns, and refusing to dress experimental calculations as medical truth. Our backend result also shows substantial working code: 102 tests passed and the 8-second build completed. The one collection error is repair work, while the larger commitment lies outside Python in iPhone signing, Bluetooth behavior, Docker services, backups, and monitoring.
A WHOOP 4.0 owner who enjoys running infrastructure may learn a lot from it. Everyone else should wait for a license, a release process, broader device evidence, and a clean fresh-environment suite. Gadgetbridge is the stronger starting point for supported Android wearables. A conventional fitness tracker is the safer choice when you need reliable daily use instead of firmware-specific research.