information security

All information Trainbase holds or handles, and everyone who works on Trainbase, staff and contractors alike.

• Public

  What it is

  The website, and the listing details of a program a coach chooses to publish.

  How it's treated

  Anyone may read it. Only its owner may change it.

• Account

  What it is

  Names, email addresses, roles, the gym a person belongs to.

  How it's treated

  Seen only by the person and the people in their gym whose role needs it.

• Health and coaching

  What it is

  Body readings and body tests, progress photos, diets and food logs, training, check-ins, readiness, habits, device readings, notes and messages.

  How it's treated

  The most sensitive. Seen only by the client, the coaches who coach them, and their gym's owner.

• Gym business

  What it is

  Programs, the gym's shared library, bookings, prospects, billing details, gym settings.

  How it's treated

  Seen only inside that gym, by the roles that need it. A coach's private library is theirs alone.

• Secrets

  What it is

  Keys and passwords that let our servers reach other services.

  How it's treated

  Never in the code, never in a browser, never written into a document.

• People in a gym reach information through the database's row rules, set by their role (see data security, section 2). Nothing in the app can widen them.
• Trainbase support reaches a gym's records in the app only by standing in that one gym, for up to four hours. Every entry, exit and change is logged where nobody can alter it, and the gym's owner can read that log. What support reads is not logged yet.
• The few people who maintain Trainbase hold administrator access to the database and hosting, through those providers' own sign-in. They use it to keep the service running and to fix faults, and they read counts and settings rather than a person's records wherever the work allows.
• Server tasks that go past the row rules use a key that lives only on our servers. Only named files may use it, an automated test fails if any other file does, and each task checks who is asking before using it.
• Secrets are kept in our hosting provider's settings and in local files that are never added to the code. Each commit made on our machines is scanned for secrets before it's saved. An audit on 24 October 2026 found none in the code's whole history.

• Before it's merged, every change to the app is run through the type checker, the code linter, the full set of automated tests and a full build. The live site isn't updated until the same checks pass again on the main branch.
• Every entry point is tested as every kind of person, including someone signed out and someone from another gym, with broken values.
• A change to the database's rules is proven on the real database before it's applied, in a transaction that is always undone, with a planted fault that must make the proof fail. Proofs that change the database run at night, Sydney time, so coaches aren't held up by them.
• Security work gets a second pair of eyes. Changes to the rules that keep gyms apart, and to the tool that runs the proofs, are checked by an independent reviewer who tries to break them.
• Database changes go live before the app code that needs them, and after a release we walk the live site.
• A release needs a named yes. New features reach the live app only on the word of one of Trainbase's founders, checked at its source. A small, proven repair to a security or correctness fault, with no new feature in it, may be released without waiting for that word.

Some work is done for us by other companies, such as hosting, email, error reports and video calls. The privacy policy lists each one, what it receives and where it runs.

Customer records are stored in Australia. A few services outside Australia do small parts of the work, and the privacy policy names each one. Before we use a new service that would receive customer data, we look for one with an Australian region. If none exists, Trainbase's founders decide, told what would cross the border and why, and the decision is written down.

• While your account is open, your records are kept so your history stays whole. Body readings, sessions and goals are kept as a timeline on purpose.
• Deleted library items sit in a bin for 30 days, then are removed for good, unless something still uses them.
• A deleted client is removed with their files and login. Our own backup copies keep them for at most 35 more days, and our database host's snapshots for at most 7. The gym keeps a record that the deletion happened, with no name and no health data.
• Uploaded video files that nothing uses are removed after about an hour.

Trainbase Pty Ltd is responsible for this policy. Questions and reports go to hello@trainbase.io.

We review this policy whenever Trainbase changes in a way that affects it, and at least once a year. When it changes, the effective date above changes too.