OpenStrap Edge reads a WHOOP band without a subscription and keeps the data on the phone

The subscription is the problem, not the hardware

Some wearables keep working perfectly well after you stop paying. The data is on the band, the sensors are unchanged, and what you lose is the vendor's cloud, its app and its membership tier. OpenStrap Edge is built around that gap. The README describes it as a health app for your wearables with no subscription, no fees, and private by default, and the repository description frames the same goal as using your health devices beyond subscriptions.

The audience is therefore people who already own the hardware and have decided the recurring fee is not worth it. That includes enthusiasts who want their data in their own hands, and anyone who simply dislikes the idea that a fitness band's history sits behind a vendor login. The project is not affiliated with or endorsed by WHOOP, Oura, Garmin or any device maker, and it says so plainly in its disclaimer, with product names used only to describe compatibility.

The implementation language is Dart, and the repository is laid out as a Flutter application with the usual platform folders. There is an android directory, an ios directory, a lib directory holding the app code, an assets directory, a test directory, a l10n.yaml for localisation, a pubspec.yaml with its lockfile, and a server directory alongside a tool directory for developer scripts. Repository topics include ble, bluetooth-low-energy, reverse-engineering, right-to-repair and on-device, which is a fairly accurate summary of the approach: talk to the device directly, keep the processing local.

WHOOP 4.0, 5.0 and MG are supported, everything else is on the roadmap

Device support is the sharpest fact in the README, and it is worth repeating because it bounds everything else. The supported list reads WHOOP 4.0, 5.0, MG. A second list is headed Being built and names Oura Ring, Garmin, Pebble, Colmi, Ultrahuman, Mi Band and more.

So today this is a WHOOP app, and the multi-device ambition is documented as work in progress rather than delivered. If your band is an Oura ring or a Garmin watch, the app cannot help you today, whatever the roadmap says. The being built framing also implies that support arrives per device family rather than per feature, since each hardware target needs its own protocol work.

That work is structured. The guides include a document on writing a device adapter, docs/ADAPTERS.md, which tells you where the per device logic lives, and the contributing section notes that changes can belong in different repositories, with CONTRIBUTING.md explaining which one. Bug reports from real devices are described as the most useful contribution, which tells you something about the maturity of the adapter work: the protocol details are being confirmed against hardware by users.

The app also documents a set of integrations around the band rather than on it. There are guides for Apple Watch setup, iOS Shortcuts, Tasker integration, an AI coach, and a document explaining what the buzz patterns on the band mean. Buzz meanings is the sort of detail that only comes from someone who has worn the device.

Data stays on the phone, and the two cloud endpoints are opt in

The privacy position is stated in one line: everything stays on your phone unless you opt in, with details in PRIVACY.md. The repository also carries a NOTICE file, a NOTICE.md, and a separate DONATE.md, and a .env.example at the top level. That env file is where the design becomes concrete, because it shows exactly which two network endpoints the app knows about and that both are optional.

The first is BACKEND_URL, described as being used only for the one time legacy account cloud import at onboarding, with the note that you can leave it blank if you have no old cloud account to pull history from and that the app is otherwise fully local, not an ongoing backend dependency. The second is COMPANION_URL, used for the OTA and announcement pointer and for the BYOK LLM proxy, and blanking it skips both, with a pointer to lib/cloud/companion_client.dart for the implementation. The example values are placeholders for your own worker deployment:

BACKEND_URL=https://your-backend.example.workers.dev
COMPANION_URL=https://your-companion.example.workers.dev

Both are described as things you can leave blank. That is a meaningful design choice, since the app works fully without either. The privacy claim and the env file agree, and the companion file reference shows where to look if you want to audit what the client does when it is enabled.

Building from source with Flutter and a dart-define env file

The README points to a development guide, docs/DEVELOPMENT.md, for building and running from source. The only build command that appears in the documentation is in the header of the .env.example, and the file is meant to be copied to .env:

# Copy to .env. Both of these are optional - the app works fully without either.
# Build with: flutter run --dart-define-from-file=.env

The flag to note is dart-define-from-file, which passes the .env values into the build as compile time defines, so the two URLs are baked into the binary at build time rather than read from the filesystem at runtime. That has a direct consequence for how you distribute a build: changing an endpoint means rebuilding, and a build shipped to someone else carries whatever values you compiled in.

For everyday use you do not build anything. The README links an Android download badge pointing at the latest release APK, and a TestFlight link for iOS, so the everyday path is an install from the releases page or from TestFlight. The guides directory also carries an iOS installation guide and a separate iOS sideload guide, which suggests the TestFlight route is not always sufficient, something that happens with iOS distribution of unofficial apps.

The release history is busy and recent: v0.11.3 published on 2026-10-13, v0.10.0 on 2026-09-25 and v0.9.29 on 2026-08-29. The version numbers are still in the zero one range, which is the clearest signal of how young the project is.

What the screens show: sleep, strain, recovery and workouts

The README leads with a row of screenshots, and the names under them are the feature summary: Today, Health, Sleep, Resting heart rate, and Workout. The repository description lists the tracking categories more fully, naming Workout Tracking, Nutrition Tracking, Wellness Exercise, Sleep, Recovery, Strain and more, and pointing to a full feature list in docs/FEATURES.md.

The category list is broader than the screenshot row, and that gap is worth noticing. A screenshot set shows what the app looks like on a good day; a feature list is where you would find out whether nutrition tracking is a full food log or a set of manual entries, and whether strain is read straight from the band or reconstructed. The README itself does not answer those questions, and the screenshots cannot either, which is the usual weakness of judging a health app from its home page. Anyone seriously evaluating it has to open docs/FEATURES.md.

The two guides for automations, Tasker integration and iOS Shortcuts, suggest the data leaves the app as well, which is the part that makes a self hosted health log useful rather than merely private. A locally stored reading that no other tool can read is a database dump. One that can be pushed into a task automation or a shortcut is data you can act on.

AGPL-3.0, no company, and a tip jar instead of a plan

The licence is AGPL-3.0, and it is the licence you would expect for a self hosted service that people might want to fork and run for themselves. The project states plainly that OpenStrap has no company, no subscription and no paywall behind it, and that if it is useful to you, a tip helps keep it going. The README lists a Bitcoin address and an EVM address for those tips.

The AGPL choice has a practical consequence for anyone thinking of building on top of it. Anyone who modifies the app and offers it to users over a network has an obligation to offer those users the corresponding source. For an individual who wants to fork it for their own devices that obligation is mostly theoretical, but it does mean a commercial product built on this code is not a free ride. The separate TRADEMARKS.md file shows the project separates the code licence from the OpenStrap name and logo.

On upkeep, the repository is not archived and the last push was on 2026-10-19, days before the current version tag was cut. The three most recent tags were cut on 2026-08-29, 2026-09-25 and 2026-10-13, so the project is still moving quickly. The vulnerability reporting route is documented separately through SECURITY.md, and the general contribution rules are in CONTRIBUTING.md.

Where OpenStrap Edge is the wrong tool

There is one large wrong case and it is the device list. If your wearable is an Oura ring, a Garmin watch, a Pebble, a Colmi ring, an Ultrahuman band or a Mi Band, this app has nothing for you yet, and the same applies to any band model that is not in the supported list. A project that names WHOOP 4.0, 5.0 and MG does not claim to cover the whole WHOOP line either, so a 3.0 or 4.5 user should check before installing.

The second wrong case is expecting the vendor's app to be matched feature for feature. A first party app has support guarantees, an updater, and a working sync with the company's backend. OpenStrap Edge is a community project whose data comes from reverse engineered protocols, and the README is candid that it is not affiliated with or endorsed by any device maker. When a vendor changes a protocol, a third party client breaks first. That is a real operational difference and it is the price of the subscription you are not paying.

The third wrong case is a shared or managed device. The privacy model assumes the phone in your pocket is yours, and the one time legacy account cloud import exists precisely so that a person moving away from a vendor account can bring their history with them. If the phone is a work device, the local data is local to that phone and the BYOK LLM proxy is your responsibility to configure.

Editorial conclusion

OpenStrap Edge is worth adopting if you own a supported WHOOP band and want the data off the vendor cloud, on your own phone, without a membership. It is the wrong tool for anyone on Oura, Garmin, Pebble, Colmi, Ultrahuman or Mi Band, since those adapters are still being built, and for anyone who needs a polished, company backed product. Before installing, read the privacy notes and the guides for your platform, decide whether the optional companion URL is acceptable in your threat model, and check the release notes for the version you are about to install, since this is a project with no company behind it and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. OpenStrap/edge on GitHub
3. Project website
4. README
5. Releases