data security

• Your records and files are stored in Sydney. Trainbase's database and its file storage (progress photos, message files, profile photos, exercise videos) are kept together with our database host, in its Sydney region.
• The app's servers run in Sydney too, beside the database. Pages reach your browser through our hosting provider's network, which serves them from the location nearest you.
• A few services sit outside Australia. Error reports go to our error-reporting service in the United States, with personal details taken out first (section 7). Emails, such as invites and password resets, are sent through our email delivery service in the United States. Video calls are set up through our video calling service, a US company: the call itself runs through its Sydney region, and it is told the names of the people joining. When paid sign-up opens, card payments go through our payment provider, and Trainbase never sees or stores a card number. The privacy policy lists every service and what each one receives.

The wall between gyms, and between people inside a gym, is built into the database itself. It isn't a filter each screen has to remember.

• Every table of customer data has the database's row rules switched on. A request is answered only with the rows the person asking may see. With no rule that lets them in, the answer is nothing.
• A client sees only their own records.
• A coach sees only the clients they coach, and their gym's shared library. They never see another coach's private foods, exercises or programs, except an item already in the plan of a client they share.
• A gym's owner sees everything in their own gym, and nothing in any other.
• A record you may not see looks exactly like a record that doesn't exist. Guessing an address tells you nothing.

There are two narrow exceptions, each built and logged on purpose:

• Trainbase support. A member of the Trainbase team can stand in one gym at a time, for up to four hours, to help that gym. Every time they enter or leave, and every change they make, is written to a log that nobody can edit or delete. The gym's owner can read that log for their own gym. What they read is not logged yet.
• Published programs. A coach can choose to list a program they own for sale. Anyone signed in to Trainbase can then see that listing's cover, title, description, price, length, the seller's name, photo and gym, and how many have sold. No set, exercise, note or client leaves the gym until a buyer receives their own copy.

A small set of server tasks need a key that goes past the row rules: sending invites, deleting an account, a data export, password resets and scheduled reminders among them. That key exists only on our servers, never in a browser. Only named files may use it, and an automated test fails if any other file tries. Each task checks who is asking, and what they may do, before it uses the key.

• We test the rules on the real database without changing it. Each test runs inside a transaction that is always undone, so nothing it writes is kept and no one's records change. Each test plants records that must stay hidden, signs in as someone who must not see them, and checks they get nothing. Each test also carries a deliberate fault that must make it fail, so a test that passes for the wrong reason is caught.
• Every change to the database's rules is tested this way before it goes live.
• Every entry point to our servers is tested as every kind of person: signed out, as a stranger, as the wrong role and as someone in another gym, with broken values. The test fails if any of them can change anything they shouldn't, or carry another gym's data out.

Between gyms, the proof covers every table. Inside one gym, the table-by-table proof that a coach can't read a client they don't coach covers some tables so far, and we are extending it to all of them.

• On the way to you: Trainbase is served only over HTTPS. The site tells browsers to use a secure connection for the next two years, so a browser that has visited won't connect any other way. Our database host accepts only TLS 1.2 or 1.3 connections to its services.
• At rest: our database host encrypts the data it stores with AES-256. Our own backup copies are encrypted before they are written anywhere (section 5).
• Your files: every storage bucket is private. A photo or file reaches your screen through a signed link that stops working after 10 to 60 minutes. A photo link inside a data export lasts 24 hours.

• Our database host's backups: our database host takes a snapshot of the database each day and keeps it for seven days.
• Our own copy: once a day we take a copy of the database with a login that can only read. It is encrypted before it touches a disk, uploaded to a separate backup storage service, downloaded again and checked against what was sent. That service reports the storage's location as Oceania. A lock rule stops any copy being deleted in its first day. Copies older than 35 days are deleted, and only once a newer copy has been checked. So a client deleted from Trainbase is gone from every copy of ours within 35 days.
• A restore has been proven. On 12 October 2026 we restored a copy into a separate database, checked every table matched the live one, and checked that every login saw only what it should.

What our backups don't do yet: the daily copy is started from our own machine rather than a fixed schedule in the cloud, and it has missed days. It covers the database, not stored files such as photos. Fixing both is open work.

• You sign in with your email address and a password of at least 8 characters.
• Your session is kept in a cookie for trainbase.io, refreshed by our servers each visit (see cookies).
• We don't offer a second sign-in step yet.

When something breaks, a report goes to our error-reporting service so we can fix it. It says where and why it broke, and as little as possible about who:

• no name, email address, login, cookie, request contents or browser headers, and no search terms or ids from the page's address;
• ids, email addresses and long numbers in an error message are masked before it leaves;
• reports from your browser go through Trainbase's own site, so that service never sees your internet address or time zone;
• errors only: no recordings of your screen and no tracking of what you do.

No SOC 2 report, no ISO 27001 certificate and no independent test by an outside security firm. We will tell you before we claim any of them.

Questions: hello@trainbase.io.