Supabase HIPAA Compliance: BAAs, Self-Hosting and What to Check

"Is Supabase HIPAA compliant?" has a short answer and a useful one.

The short answer: no product is HIPAA compliant on its own. HIPAA governs how your organization handles protected health information (PHI), and there's no official certification for software. Google's HIPAA page points out that the US Department of Health and Human Services (HHS) doesn't offer a certification program. What Supabase can do is sign a Business Associate Agreement (BAA) and give you the controls you need on its platform. The rest is up to you.

The useful answer depends on where Supabase runs: on Supabase's cloud, or self-hosted on infrastructure you control. Below is what each path requires, then the checklist we work through on health products, drawn from building the HIPAA-safe authentication, payments and data layer for Crosby Health.

This isn't legal advice. It's an engineering guide. Your obligations depend on whether you're a covered entity or a business associate and on your contracts, so confirm your plan with a healthcare compliance advisor or attorney. We checked every Supabase and Google Cloud detail below against their documentation on October 27, 2026. Both change, so check the linked pages before you sign anything.

The two paths at a glance

Path 1: Supabase Cloud with a BAA

Supabase's HIPAA compliance page says customers must sign a BAA with Supabase before storing PHI. Getting there takes three things:

• The right plan. The shared responsibility model says you need to be at least on the Team plan to sign a BAA. The pricing page lists Team from $599 a month and HIPAA as a paid add-on on Team and Enterprise. The add-on's price isn't published.
• A signed BAA and the add-on enabled. You request the BAA through the form linked from the HIPAA projects guide. An organization handling PHI needs both.
• High Compliance projects. With the add-on on, you mark projects as High Compliance in the project settings. Supabase then runs extra checks against the project's configuration and reports problems in the Security Advisor.

The guide and the shared responsibility model list the settings you're expected to turn on:

• Point-in-time recovery, which needs at least a Small compute add-on and costs $100 a month per 7 days of retention.
• SSL enforcement.
• Network restrictions, so only addresses you allow can reach the database.
• Postgres connection logging. Supabase sets log_connections to off for new projects, and HIPAA projects should keep it on for the audit trail.
• MFA on every Supabase account, enforced for the organization.

There are also two things not to do: store PHI in public Storage buckets, or transfer a HIPAA project to an organization without HIPAA. Supabase encrypts data at rest and in transit, and suggests considering application-level encryption on top.

One line in Supabase's docs is worth reading twice: applying the recommended controls is the customer's job. The BAA makes Supabase your business associate. It doesn't configure your project or write your access rules.

Budget the floor before you choose this path: the Team plan, the HIPAA add-on, a Small compute add-on for each project and PITR, all before usage.

Path 2: Self-hosting on a cloud that signs a BAA

Supabase is direct about this one. Its HIPAA page says the controls "are not supported out of the box in self-hosted Supabase" and calls HIPAA compliance for self-hosted Supabase out of scope for its documentation. Supabase the company isn't in your data path when you run the software yourself, so the agreements that matter are with your cloud provider and the other vendors that touch PHI.

Google Cloud's HIPAA page says Google enters into BAAs as necessary under HIPAA, and you review and accept the Google Cloud BAA for your account. Its list of covered products includes everything a setup like ours uses: Compute Engine, Cloud SQL, Cloud Storage, Cloud Load Balancing, Cloud Armor, Cloud NAT, VPC, Secret Manager, Cloud Logging, Cloud Monitoring and Memorystore, plus GKE and Cloud Run if you go that way. Some entries carry product-specific notes, so read them for the products you use.

Three points on that page shape the design:

• "Complying with HIPAA is a shared responsibility between you and Google." Google provides the infrastructure controls. Configuring and securing your environment and applications is on you.
• If you can't disable a service, you must not use it for PHI.
• Pre-GA products aren't covered unless Google says otherwise.

So the cloud gives you a covered foundation. Everything Supabase's platform would have done, and everything you'd do anyway, is now yours. That starts with the operational work in Self-Hosted Supabase in Production: upgrades, backups, monitoring and keeping Studio private. HIPAA then adds:

• The technical safeguards in the HIPAA Security Rule (45 CFR 164.312): access control, audit controls, integrity, person or entity authentication and transmission security. Within access control, unique user identification and an emergency access procedure are required; automatic logoff and encryption are addressable.
• The administrative safeguards (45 CFR 164.308), including a risk analysis, risk management and regular review of activity records such as audit logs, all marked required.
• Business associate agreements with every vendor that creates, receives, maintains or transmits PHI for you: email, error tracking, analytics, support tools.

"Addressable" doesn't mean optional. Under 45 CFR 164.306(d), you assess whether the safeguard is reasonable and appropriate for you and implement it if it is. If it isn't, you document why and implement an equivalent alternative where that's reasonable.

One trap specific to self-hosting: Studio sits behind a single basic-auth login and can read and change every table. A shared login is hard to square with unique user identification if anyone uses Studio on production PHI. Either keep Studio away from production data, or put per-person identity in front of it, such as a VPN with individual access keys like ours, and log who connected.

The engineering checklist

This is the list we work through on health products, on either path. Crosby Health, where we owned authentication, payments and the data layer for a platform that helps medical groups run CMS care programs, wasn't built on Supabase; it runs on TypeScript, Node.js and PostgreSQL. The controls carry over, and they're where most of the work is.

1. Map where PHI goes. Tables, file buckets, logs, emails, analytics events, backups, support tools and every vendor. You can't protect a copy you don't know exists.
2. Give everyone their own identity. No shared logins anywhere, including Studio, the database and cloud consoles. Service credentials stay on servers, and Supabase's secret key never ships to a client.
3. Scope access to the record. At Crosby, each person sees only the patients and records their role allows. In Supabase, that means Row Level Security policies built on the user's ID and role, tested with real accounts for each role. Our Supabase security checklist shows how to find the gaps.
4. Require MFA. Supabase Auth supports authenticator apps (TOTP) and phone factors, and an RLS policy can require the aal2 assurance level, so data is only reachable after the second factor (MFA docs).
5. Log access, then review the logs. Record who viewed or changed which record and when. Postgres connection logging and pgAudit, which Supabase documents and Cloud SQL supports, cover the database. Your API should log record-level access too. The Security Rule expects regular review, so someone has to read them.
6. Keep PHI out of logs. At Crosby we put real care into PHI-safe logging, so debugging production never means exposing patient data. Scrub request bodies, keep names and dates of birth out of error messages, and check what your error tracker captures by default.
7. Encrypt in transit and at rest. TLS everywhere, with SSL enforced on database connections. Both Supabase and Google Cloud encrypt stored data by default. Add application-level encryption for the fields that would do the most harm if leaked.
8. Keep files private. Private buckets only, with short-lived signed URLs for downloads.
9. Close the network. Network restrictions on Supabase Cloud. Private IPs, a VPN and an allowlist when self-hosting.
10. Back up, and test restores. Point-in-time recovery, backups kept in covered services, and restores you've actually run.
11. Time out idle sessions. Automatic logoff is addressable, which in practice means short sessions for staff tools.
12. Write it down. The risk analysis, the policies and the reasoning behind each addressable safeguard. When an auditor or a hospital's security team asks, the documents are what they read.

What it adds to a build

In our estimator, HIPAA adds 4 to 8 days of engineering to a product, covering the access controls, audit logs and encryption above. Formal audits, legal review and the hosting plan come on top. For a health app on web and mobile with bookings, secure messages and file sharing, that's the difference between $23,000 to $92,000 and $27,000 to $105,000 at $100 to $150 an hour. The full breakdown is in How Much Does It Cost to Build an App in 2026?

Where we come in

We build the compliance side of products: the access model, audit logging, PHI-safe logging and the infrastructure under it. Besides Crosby Health, we moved Hexis to a multi-region Google Cloud platform, where its SOC 2 audit is in progress. See HIPAA and SOC 2 engineering, or self-hosted Supabase if you want the database in your own cloud account.