Publish a workout pack.

The shape of the deal

1. You write a manifest.json describing your repository (name, author, homepage) with all your workouts embedded inline.
2. You host it over HTTPS, anywhere that serves a JSON file with permissive CORS. GitHub Pages, Codeberg Pages, your own web folder.
3. You open a pull request against this app's Codeberg repository adding a single entry to website/registry.json that points at your manifest URL.
4. On merge, your repository shows up in the community browser and is subscribable from inside the app.

1. Write your manifest (and bundles)

A repository is two kinds of file:

• One small manifest.json with repo metadata plus a list of pointers to your bundle files. The app downloads this on every refresh, so keeping it small (just metadata, no segments) keeps everyone's bandwidth low.
• One or more bundle files, each a JSON array of workout objects. The app downloads a bundle only when its content version changes, so unrelated workouts stay cached when you edit one.

Manifest top-level fields

Each bundle entry

Each workout (inside a bundle file)

A bundle file is a JSON array; each element is a workout object:

Example: minimum viable repo

Two files. Copy, edit, host.

manifest.json

{
  "schemaVersion": 2,
  "id": "alpine-coach",
  "name": "Alpine Coach",
  "description": "Threshold and VO2 work tuned for stage racers.",
  "author": "Alpine Coach Collective",
  "homepage": "https://alpinecoach.example",
  "updatedEpoch": 1746547200000,
  "bundles": [
    {
      "id": "main",
      "schemaVersion": 1,
      "version": 1,
      "url": "main.json"
    }
  ]
}

main.json (sibling of the manifest):

[
  {
    "schemaVersion": 1,
    "id": "alpine-warmup-2min",
    "name": "Quick Warmup",
    "description": "Two-minute pre-effort opener.",
    "tags": ["Warm-up"],
    "segments": [
      { "lengthInSeconds": 60, "powerPercentFTP": 50, "intervalType": "CONSTANT" },
      { "lengthInSeconds": 60, "powerPercentFTP": 75, "intervalType": "CONSTANT" }
    ]
  }
]

For a longer reference, see the starter pack manifest and its main bundle: six workouts spanning warm-up through VO2.

Splitting workouts across multiple bundles

For small repos, one bundle is fine. Split when you have logical groups that change at different rates: e.g. weekly-plan bumped every Monday and warmups updated rarely. Riders only re-download the bundle whose version moved.

2. Host it

The app fetches your manifest over plain HTTPS. Anywhere that serves static JSON works. Two things matter:

• HTTPS only. The app rejects http:// on import (defense against tampering on hostile networks).
• CORS. Your host must send Access-Control-Allow-Origin: * (or include indoorbike.app) so the community browser's fetch() can read your manifest. Without this, your repo will work in the Android app but won't preview on the website. GitHub Pages, Codeberg Pages, and Cloudflare Pages all set this header by default for static files.

Test your URL by opening it directly in a browser. If you see your JSON, you're good. If you see "blocked by CORS" in the devtools console, fix your host's headers.

3. Submit to the registry

Listing your repo in the community browser is a one-line addition to website/registry.json. Open a pull request on the app's Codeberg repository:

1. Fork the repository.
2. Edit website/registry.json and append a new entry to the repositories array. The fields:

   {
     "id": "alpine-coach",
     "name": "Alpine Coach",
     "description": "Threshold and VO2 work tuned for stage racers.",
     "author": "Alpine Coach Collective",
     "manifestUrl": "https://alpinecoach.example/manifest.json",
     "tags": ["Threshold", "VO2 Max"],
     "homepage": "https://alpinecoach.example"
   }

   The id here must match the id in your manifest. tags here are repo-level (shown on the card); they're independent from per-workout tags.
3. Open a pull request with a short note about who you are and what the pack covers.

On merge, your repo appears in the community list within minutes (just a static-site rebuild). No backend, no account, no review queue beyond a quick sanity check that the manifest URL is reachable and the JSON parses.

Updating after publication

• Editing a workout: change the bundle file, then bump that bundle's version in the manifest. The app will see the bumped number on next refresh and re-download just that bundle. Other bundles stay cached.
• Adding a workout: drop it into an existing bundle file, bump that bundle's version. Or create a new bundle file and add a fresh entry to the bundles array.
• Removing a workout: remove it from the bundle file and bump that bundle's version. Existing subscribers stop seeing it after the next refresh. Past rides of that workout stay in their ride history.
• Renaming or rebranding the repo: change the manifest's name, description, etc., but don't change the id. The id is the identity; changing it makes the app think it's a different repo.
• Bumping updatedEpoch: optional, but worth setting on each release so users see "updated 2 days ago" rather than a stale timestamp.

Style guidelines (suggestions, not gates)

• Prefix workout ids with your repo id. Two repos shipping "tempo-3x10" would clash inside the app, and the dedup rule (Imported > Subscribed > Bundled, first-wins) may not pick the one your user wanted.
• Keep powerPercentFTP realistic. The app accepts 0–300, but anything above ~150 is sprint territory and most trainers will struggle to actually deliver it in ERG.
• Open with a warm-up, close with a cool-down. Saves your riders from cold-start TSS spikes.
• Plain-text descriptions. Markdown isn't rendered anywhere; line breaks are.