Endurance training without the cloud

Journal · 2026-09-15 · R. Klug · All notes

Read in: Deutsch · Français · Español · Italiano

Endurance training runs on a long memory: baselines built over months, threshold history over seasons, the slow drift of resting physiology over years. The default architecture for holding that memory is someone else’s server. It is worth asking, function by function, what in a training setup actually requires one — because the answer is shorter than the industry’s architecture suggests.

The four functions, separated

• Recording. Sensors speak Bluetooth to the device in your pocket. A chest strap’s RR intervals, a Concept2’s power, a Loop’s night — none of it passes through the internet on its way to your phone. Recording is local by physics; clouds are added afterwards.
• Analysis. HRV statistics, DFA α1, threshold estimates, baselines — this is arithmetic over files, and everything ampulse computes runs comfortably on the phone itself.
• Storage. A year of nights and sessions, stored as interval-level files, occupies less space than a short video. Storage is not the reason either.
• Sharing. The one genuinely network-shaped function. Posting a session to Strava, sending a file to a coach, letting an assistant read your record — each is a deliberate transfer of a specific file to a specific party. A share needs a connection; a record does not.

So the honest architecture is: record locally, analyse locally, store locally, and share by explicit act. That is how ampulse is built — the airplane-mode test is a fair one: nights sync, sessions record, analysis runs. The operations that need a network are the ones that name their counterpart: a Strava upload you trigger, a Loop firmware update from Polar’s service.

What the cloud contract costs

Cloud platforms fail in ways that have nothing to do with your training. Recent years supplied the full catalogue: multi-day platform outages during which nothing could sync, third-party API access revoked overnight, services sunset with an export deadline, features moved behind new subscription tiers, and processed summaries whose methods changed silently between app versions. None of these are scandals exactly — they are the normal behaviour of services over a decade. The point is that a multi-year training record should not inherit the lifespan and terms of a service.

An open file carries no such dependency. A FIT or CSV file written in 2026 opens in 2036 regardless of which companies still exist, which the analysis tools of that year will read natively, and which algorithms will have improved by then — a stored interval sequence can be re-analysed under methods that had not been invented when it was recorded. A processed score, by contrast, is frozen at the intelligence of the day it was computed.

What you give up, stated honestly

No cloud means no cross-device magic: your record lives on your iPhone (an iCloud Drive folder can mirror the files through Apple, under your Apple ID, if you choose). It means no social feed and no server-side coaching. And it means backup is your responsibility — the same responsibility you carry for your photos, solved the same way: the files export as ordinary files precisely so they can live in whatever backup you already trust.

The practical setup

• Nights: Polar Loop synced directly over Bluetooth, or sleep imported from Apple Health — how the direct connection works.
• Sessions: an RR-capable strap for physiology, PM5/FTMS for power — recording raw RR from an H10.
• Analysis elsewhere when you want it: export FIT, CSV or Kubios RR and use any tool — the record is portable because it was never captive.