Security & Data Privacy
When you use Heelr, you're trusting us with information about your shelter — your volunteers, your animals, and your operational data. This page explains how that data is protected, who can access it, and what infrastructure it runs on.
Your shelter's data is yours
Heelr is a multi-tenant application, meaning multiple shelters run on the same platform. Every piece of data — dogs, users, activities, audit logs — is tagged with a shelter identifier at the time it's created. That identifier is never editable after the fact.
No one at another shelter can see, search, or modify your data. This isn't just a rule in our application code — it's enforced by the database itself (see below).
Database-level isolation
Heelr runs on PostgreSQL with Row Level Security (RLS) enabled on every table. RLS means the database engine evaluates an access policy on every single query before returning any rows — even if the application code forgot to filter, the database won't return data that doesn't belong to your shelter.
In plain terms: a bug in our application code cannot expose one shelter's data to another. The isolation guarantee lives below the application layer.
Role-based access within your shelter
Within your shelter, access is controlled by role:
| Role | What they can do |
|---|---|
| Volunteer | Read dog profiles and activity history, log activities for eligible dogs |
| Staff | Everything volunteers can do, plus edit dogs and manage activities |
| Admin | Everything staff can do, plus manage users and shelter settings |
Admins can only manage users within their own shelter. There is no cross-shelter admin access.
Certain dogs are additionally restricted by handling certification — volunteers without special handling certification cannot log activities for those dogs, regardless of their role.
Authentication
Passwords are never stored in Heelr's application database. Authentication is handled by Supabase Auth, which stores credentials separately using bcrypt hashing. Sessions use short-lived signed tokens (JWTs) that expire automatically.
Password changes and email address changes both require verification of the current password before taking effect.
Infrastructure
Heelr's database and authentication run on Supabase, which provides:
- SOC 2 Type II certification
- Encryption at rest (AES-256)
- Encryption in transit (TLS)
- Hosted on AWS infrastructure
Supabase's full security and compliance documentation is available at supabase.com/security.
What we're working toward
Heelr is an early-stage product. We don't yet hold independent certifications like SOC 2 or ISO 27001, and we haven't completed a formal third-party penetration test. Those are on our roadmap as we grow.
What we can say today: the data isolation architecture is sound and enforced at the database level, the infrastructure we build on carries enterprise-grade certifications, and we take security seriously enough to tell you honestly where we are rather than oversell it.
Questions?
If you have specific security questions — about our architecture, data handling practices, or a particular concern — reach out at hello@heelr.app. We're happy to walk through the details.