Enforced at the
database.
Not by what a screen chooses to render. Every table in Repple carries row-level rules keyed to the account asking and, where it matters, to the gym that account belongs to. This page is the mechanism — who can read what, why a coach cannot see your progress photos, and what deletion actually removes. The policy version of the same ground is in Privacy.
A screen that decides what to show you is a preference. A row your account cannot read is a fact.
Hidden buttons and filtered lists are how most software describes its permissions. They protect nothing: the request underneath them is still allowed, and anything that can make that request — a rebuilt app, a copied key, a curl command — gets the data anyway.
- The rules live under the data, not over it. A read that a policy forbids returns nothing, whichever app asked and however the request was made.
- Your gym is the fence, and it is per gym. The test is not “is this caller an owner” but “is this caller the owner of this gym”. Those are different questions and only the second one is safe.
- One implementation per figure. The web console and the phone app call the same functions over the same rows through the same permissions, so a number cannot read one way at the desk and another way on a phone.
- Health data is never sold or shared for advertising. It is used to show you your training. There is no other purpose in the system for it to be used for.
Three parties,
and one of them is you.
Your gym and your coach are not the same audience and do not get the same access. A gym needs what it takes to run the place. A coach needs what it takes to program for you. The two lists are genuinely different, and neither of them is everything.
| What is recorded | You | Your coach, if you linked one | Your gym, if you are a member of one |
|---|---|---|---|
| Sessions, sets, cardio | Read and write | Read only | No |
| Meals and food log | Read and write | Read only | No |
| Scans, measurements, check-ins, habits | Read and write | Read only | No |
| Progress photos | Read and write | No — deliberately, at both layers | No |
| Messages with your coach | Read and write your own | Read and write their own | No — an owner has no access to these |
| Membership, payments, invoices | Read your own | No | The owner, for the gym they own |
| Door visits | Read your own | No, not as your coach | The owner, and staff working the desk |
| Class roster | Your own bookings | The trainer taking that class | The owner of that class's gym |
“Read only” is literal: a coach's access to your training record is a read permission and not a write one, and it exists only while the coaching link does. End the link and the access ends with it. A trainer who works the desk at your gym sees the door log because that is a staff job, not because they are anybody's coach.
A private bucket
The store your photos go into is not public. Access is keyed to a folder named after your own account, and nothing else can write into it or read out of it.
Links that expire
A photo is fetched through a temporary signed link that you mint by asking for it. There is no permanent address that would keep working if it leaked.
No coach access, and it was removed on purpose
A read permission for the linked coach existed and has been taken out. It is not an oversight waiting to be corrected, and the reasoning is written into the schema so nobody re-adds it by copying the pattern from the tables either side of it.
A photograph is not
another number.
Every other thing a coach can read about you is a figure you chose to record for them to coach against. A progress photo is typically taken in underwear, alone, in a bathroom. A coach seeing your body-fat percentage is the product working; a coach seeing that photograph without you choosing it is a different act entirely.
- There is no consent step yet. No per-photo sharing control, no indicator that anyone else can see them, no way to take it back. Access without those means people upload believing it is private and are wrong.
- Sharing has to be something you do. Not something that is quietly true because of who your coach is.
- It bought nothing. Nothing in the coach app displays a client's progress photos, so the permission granted access no screen was using — a standing exposure with no feature behind it.
- Latent access is worse than open access. The day somebody adds a coach-side viewer, the photos would have become visible with no review of consent, because the hard part already looked done.
When per-photo sharing is built, it needs three things together: a flag on the photo, a read rule gated on that flag, and a matching rule on the file itself — because the record and the image are granted separately. Until all three exist, the answer is no at both layers.
Six things that stop it
being decorative.
A permission system is only as good as the ways around it. These are the ones that were found by reviewing the whole schema rather than the feature being worked on, and each is closed in a way that keeps closing as the system grows.
This gym's owner, not an owner
The eight-word difference that matters most. A rule testing only that the caller holds the owner role opens every gym on the platform to any owner. Every rule tests ownership of the specific gym the row belongs to.
You cannot promote yourself
Row-level rules cannot restrict which columns an update touches, so a rule letting you edit your own profile also let you set your own role and move yourself into somebody else's gym. A trigger refuses both. Joining a gym happens by invitation, and there is no other path.
Nothing is callable signed out
Postgres grants execute on a new function to everyone by default, and recreating a function to fix something else quietly restores that default. So the grants are re-applied as a sweep over the catalogue rather than a list of names that would go stale the first time somebody adds one.
A policy without RLS is inert
A rule written for a table that never had row-level security switched on looks like protection in the migration and is never consulted. Four tables were missing it, two of them carrying rules that had therefore done nothing since the day they were written. The fix asserts that security is on before it writes a rule, and fails loudly if it is not.
The key inside the app opens nothing
A public key is compiled into every shipped mobile app; that is how they are built, and anyone can extract it. It is not a credential here. Every rule is written against the signed-in account, so holding the key without an account gets you nothing.
Server keys are never in code
The privileged key used for background work is read from a secret store at the moment it is needed, not written into a function body where anything able to read the schema could read it too.
A delete button that only
sets a flag is a lie.
Deletion in Repple removes the account itself, and the account is what the rest of the data hangs from — so it goes by construction rather than by a hand-maintained list of statements that would drift the first time somebody added a table.
What deleting an account reaches
-
1
You ask, in the app or by email
Settings has the request; support@repplefitness.com reaches a person if you would rather it went that way.
-
2
There is a window, and you can take it back
Thirty days, and withdrawing is a real operation rather than a sentence on a page — there is a function that clears the request, because a grace period nothing can undo is not a grace period.
-
3
Your gym can see it, and only that
A gym owner sees the pending requests for their own gym: who asked, when, and how long is left. Not a general window onto member records — just what is needed to act on it.
-
4
The record of the deletion is written first
Afterwards the profile is gone and there is nothing left to read a name or a gym from. So the audit row goes in before the delete, which is what lets a gym show its own compliance record once the person no longer exists.
-
5
It can only be actioned for someone who asked
A gym cannot use this to remove a member who has not requested it. That would be a deletion tool wearing a compliance label, and the function refuses it.
-
6
The files are chased separately, and confirmed
Deleting a database row does not delete an image in object storage — there is no cascade between the two. So the file's location is recorded before the row is gone, a delete is sent for it, and it is marked done only on a reply that actually says the object is no longer there. Nothing is marked deleted because it asked nicely.
Deleting your account sets out the same ground for a member, including what survives and how to ask.
One database,
one file store.
The full list of the services that process data on our behalf, and what each one is for, is in Privacy.
What this page
does not claim.
A security page is a place where confident language is cheap, so here is the boundary of what is being asserted above.
No certification, no audit report
Nothing here is one, and none is cited. The review that produced most of what is on this page was our own reading of the whole schema, not a third party's.
No uptime figure
Repple has not launched publicly, so there is no period long enough to quote an availability number from. A figure without that behind it would be decoration.
No promise of perfection
Several of the protections described above exist because the same review found the problems they fix. That is what a review is for. It is also a reason to say plainly that the count of what has not been found yet is unknown, as it always is.
If you find something wrong, tell us and it gets fixed: support@repplefitness.com. There is no disclosure programme to enrol in and no form to fill out first.
Straight answers
Can my gym read my training log?
No. A gym sees the membership and attendance information it needs to run the place — what you are on, what you have paid, when you came in, which classes you booked. Your sessions, sets, meals, scans and photographs are not part of that, and there is no rule anywhere that would let an owner read them.
Can my coach read my messages with a different coach?
No. A message is readable by the two people in that conversation and nobody else — not another coach, and not the gym's owner.
What happens to my coach's access when I end the link?
It ends with it. Their read permission is written against the live coaching link, so it is not a copy of your data that they keep — it is a view that stops resolving.
Could another gym see our records?
Every rule is keyed to the specific gym a row belongs to, and being an owner somewhere is not the same as being the owner of your gym. That distinction is the single most common way a system like this leaks, and it is why every rule tests the second thing rather than the first.
Will you ever let coaches see progress photos?
Only behind a control you operate, per photo, that you can withdraw. Anything less is people uploading in the belief it is private and being wrong, which is the outcome the current answer exists to prevent. Until that control is built, the answer is no.
Does deleting my account delete my gym's records of me?
Partly, and the split matters. Your membership and your invoices go with you. Payments taken, door visits and passes stay as rows with you detached from them, because a gym has tax and legal reasons to keep the fact that money moved. Deleting your account lists both sides.
Do people at Repple look at my data?
Not as a matter of routine. Support work occasionally needs somebody to look at an account to answer the question you asked, and that is the only reason it happens.
Ask us anything here.
Including the awkward questions. A due-diligence email gets a straight answer, and a “we have not built that” where that is the truth.