Security
Last reviewed: September 2026
How we protect your data
Encryption in transit
All communication between the Repaired app and our servers uses TLS 1.2 or higher. Data is never transmitted unencrypted.
Encryption at rest
User data is stored in AWS infrastructure and encrypted at rest using AES-256. Authentication credentials are managed through AWS Cognito and are never stored in plain text.
Structural privacy
Repaired is built around a privacy-until-submit model. Your reflections, feelings, and responses are not shared with your partner until you explicitly submit them. They are not readable by any third party, coach, or algorithm during the flow. This is not a setting. It is how the protocol works.
What we do not store
- We do not store payment card data. Payments are handled by Stripe.
- We do not sell user data to third parties.
- We do not use conflict content for advertising or model training.
Authentication
Sign-in runs through AWS Cognito: email and password, an emailed sign-in link, or Google or Facebook. Passwords are hashed and salted. On the web, the sign-in token is kept in an httpOnly cookie that page scripts cannot read, and in the apps it is kept in the device’s secure storage. It is never logged or included in URLs.
Infrastructure
Repaired runs on AWS infrastructure in the us-east-1 region. We use AppSync (GraphQL API), DynamoDB, and S3 with IAM least-privilege access controls. No server-side secrets are committed to source control.
Backups and recovery
Every production database table has point-in-time recovery enabled, giving a rolling 35-day window we can restore from if something goes wrong. Tables also carry deletion protection at the AWS API level, as does the user directory, so neither can be removed by a mistaken command or a misconfigured deploy.
These protections are defined in infrastructure-as-code rather than clicked into a console, which means they are re-applied on every deployment instead of depending on someone remembering.
Access control
Administrative access is gated on membership of a specific group in the user directory and enforced in middleware, before any admin page or API route runs. It is not a hidden URL or a client-side check.
Our own infrastructure credentials follow least privilege: the day-to-day deployment identity is deliberately not an administrator, and it carries explicit deny rules over the most expensive and most destructive classes of operation.
Deleting your data
You can delete your account from your profile settings on the web. Deletion removes your account and the content attached to it rather than hiding it, and it is a self-service action: you do not need to email anyone or wait for approval. What is and is not removed is set out in the Privacy Policy.
What we are still working on
We would rather be specific than reassuring. Repaired is pre-launch and run by a single developer, so some things a larger company would have are not in place yet: there is no third-party penetration test, no SOC 2 report, and no bug bounty program. We are not claiming otherwise. If any of those are a requirement for you, this is the honest answer today.
Responsible disclosure
If you discover a security vulnerability in Repaired, please report it to us privately before disclosing it publicly. We will acknowledge receipt within two business days and work to resolve confirmed vulnerabilities promptly.
Email: hello@repairedapp.com
Please include a description of the vulnerability, the steps to reproduce it, and the potential impact. We do not currently operate a bug bounty program, but we will acknowledge your contribution publicly if you wish.
Questions
For general security questions not related to vulnerability disclosure, email hello@repairedapp.com.
Where to go next
- Privacy Policy
What we collect, why, and how long it is kept.
- Who can read what you write
The short answer, without the legal phrasing.