Supabase signs a BAA on the Team plan and up, with its paid HIPAA add-on, and only for projects you configure as high compliance. Free, Pro and self-hosted Supabase get no BAA. Here is what the BAA requires, what Vercel and Lovable add to the picture, and how to put PHI behind a backend that is covered. Checked against vendor docs on 2 October 2026.
[ KEY TAKEAWAYS ]
Yes, with conditions you have to buy and configure. Supabase signs a Business Associate Agreement only for organizations on the Team plan or higher that add its paid HIPAA add-on, and only projects you switch to high compliance are in scope. Free, Pro and self-hosted Supabase get no BAA. And a covered database is one piece of the app: Lovable, Vercel, your auth emails, analytics and AI calls each need their own answer.
lowest Supabase plan that can sign a BAA. Listed from $599 a month, HIPAA add-on extra.
settings Supabase requires on a HIPAA project, from enforced MFA to connection logging.
a month, Vercel's listed HIPAA BAA add-on for Pro teams.
mentions of HIPAA or a BAA on Lovable's security pages when we checked.
We take AI-built healthcare apps to production, so this question reaches us almost every week in some form. On 2 October 2026 we read 650 Upwork job posts for a demand study, and the same request kept showing up in different words: "we built it in Lovable on Supabase and Vercel, now we need it HIPAA compliant," or "build an isolated PHI backend next to our existing app." This page is the answer we give on those calls, with the vendor terms checked the same day.
Supabase's shared responsibility model is direct about it: "You will need to be at least on the Team Plan to sign a BAA with us." Its HIPAA projects page adds that the organization needs a signed BAA and the HIPAA add-on enabled before it deals with PHI. On self-hosting, the HIPAA compliance page says the hosted platform has the controls, and "these controls are not supported out of the box in self-hosted Supabase."
| Supabase setup | BAA available? | What it means for PHI |
|---|---|---|
| Free | No | Fine for a demo with fake data. No real patient data. |
| Pro | No | Same as Free for HIPAA purposes. This is where most Lovable and Bolt projects sit when the question comes up. |
| Team | With HIPAA add-on | Listed from $599 a month on Supabase's pricing page, which shows "HIPAA available as paid add-on." Sign the BAA, then mark each PHI project high compliance. |
| Enterprise | With HIPAA add-on | Same BAA route, negotiated terms. |
| Self-hosted | Not from Supabase | You run it, so you own every control and every BAA with your cloud provider. Supabase calls this out of scope for its docs. |
Signing the BAA turns on extra checks in Supabase's Security Advisor, and the advisor tells you when a project drifts. Fixing what it reports is on you. The shared responsibility page lists the customer side for healthcare data, and in plain words it comes to this:
Accounts
MFA on every Supabase account
Every person who can log in to the dashboard uses MFA, and the organization enforces it. One teammate without it is a finding.
Projects
High compliance switched on
Each project that holds PHI is marked as a HIPAA project in General Settings, and the advisor's warnings get fixed, not dismissed.
Recovery
Point-in-time recovery
PITR has to be on, and Supabase notes it needs at least a small compute add-on. Daily backups alone don't meet the requirement.
Network
SSL enforcement and network restrictions
The database refuses unencrypted connections and accepts them only from addresses you allow.
Logging
Connection logging stays on
New projects ship with Postgres connection logging off. HIPAA projects keep it on for the audit trail.
Storage
No PHI in public buckets
A public bucket serves files to anyone with the URL. Intake forms, IDs and lab PDFs go in private buckets behind policies. And a HIPAA project can't be moved to a non-HIPAA organization.
None of that touches your application code. Supabase also reminds you, in the same document, that you're responsible for access to tables with sensitive data and that it recommends row level security everywhere. That's where AI-built apps usually fail, and it's covered further down.
A typical AI-built healthcare app has five to ten services that can see patient data. The BAA with Supabase covers Supabase. Each of the others is a separate business associate, or it has to be kept away from PHI completely. Vercel's own HIPAA guide puts it the same way: "the BAA chain has to extend all the way down your stack."
| Piece of the app | BAA path | What we check first |
|---|---|---|
| Supabase database, auth, storage | Team+ with add-on | Plan, add-on, high compliance flag, RLS on every table with PHI, private buckets, service role key never in the browser. |
| Vercel hosting and functions | Pro add-on or Enterprise | Vercel's compliance page says it signs BAAs with "eligible Pro and Enterprise customers." Its guide lists the CDN, Functions, build pipeline, environment variables and Static IPs as covered. Preview deployments shouldn't see real PHI. Secure Compute is Enterprise only. |
| Lovable editor and Lovable Cloud | None stated | Lovable's DPA has customers agree not to provide PHI, and its security page doesn't mention a BAA. Keep real patient data out of the editor, its chat and the built-in Cloud backend. |
| Auth emails and SMS | Depends on provider | A magic link is fine. An email that says "your results from Dr. X are ready" is PHI. Use a provider that signs a BAA or keep the text generic. |
| Analytics, session replay, ad pixels | Depends on vendor | Session replay on an intake form records PHI. Ad pixels on logged-in pages are the most common miss we find. |
| Error tracking and logs | Depends on vendor | Stack traces carry request bodies. Scrub them or use a vendor under a BAA. |
| AI calls (OpenAI, Claude, others) | Plan and API specific | Consumer plans have no BAA. For Claude, see which Claude plans Anthropic's BAA covers. |
| Edge functions calling outside APIs | Each API separately | Supabase's shared responsibility page lists calls to external APIs from Edge Functions and Postgres triggers as your responsibility. |
The question to ask about each row
Can this service ever see a name, a date of birth, a diagnosis or anything else that ties a person to their health? If yes, it needs a BAA or it needs to stop seeing that data. There isn't a third option.
Built it in Lovable, need it to hold PHI?
Send us the repo. We read the code, the Supabase settings and every service the app calls, and tell you what stays, what moves and what has to change before real patients use it.
New Lovable projects get Lovable Cloud by default, a built-in backend that Lovable runs for you on Supabase's open-source foundation. You don't have a Supabase organization of your own in that setup, so you can't buy Supabase's HIPAA add-on for it. Lovable's data processing agreement goes further: "the Customer agrees not to upload, input, or otherwise provide any protected health information under HIPAA." Its terms allow an exception only where a plan or a separate written agreement expressly permits it. Unless you have that agreement in writing, PHI doesn't go into Lovable Cloud.
Lovable's docs also say there's no one-click migration from Cloud to your own Supabase project: you export the data, connect a Supabase project to a new Lovable project and rebuild the schema. Worth knowing before you put months of features on Cloud. If the app will ever hold PHI, start it on your own Supabase organization, or plan the move now while the schema is small.
Most founders who call us assume they have to rebuild. Usually they don't. The choice comes down to how much of the app touches PHI and how much the current code can be trusted.
Upgrade in place
Move to Supabase Team with the HIPAA add-on, sign the BAA, switch the PHI projects to high compliance and fix what the Security Advisor and an RLS review find. Add the Vercel BAA. Right when the codebase is reasonably clean and PHI is spread through most of the app anyway.
Isolated PHI backend
Keep the Lovable front end and the Supabase project for everything that isn't PHI. Put patient data behind a small separate API in your own cloud account under a BAA. On AWS, RDS, Cognito and Bedrock are all on the HIPAA eligible services list. The app asks that API for PHI and never stores it. This is the setup Upwork buyers keep describing, and it fits when PHI lives in a few screens (intake, notes, results).
Rebuild the core
Only when the audit shows the data model can't support access rules, or when security fixes would touch nearly every file. Even then the UI and the business rules usually survive.
The isolated backend is the one people haven't heard of, and it often costs less than it sounds. The front end stops being in scope for most of the PHI questions, the BAA list gets shorter, and the part of the system an auditor reads in detail is small enough to review line by line. For the longer version of this pattern on AWS, see our HIPAA guide for SaaS developers.
Supabase exposes your database to the browser through its API, and row level security is the thing that decides which rows each logged-in user gets back. When AI tools generate a schema they often create tables without RLS, or with a policy that lets any signed-in user read every row, because that makes the demo work. Nothing looks wrong until a patient opens the network tab.
When we audit a Supabase app for PHI, these are the checks we run before anything else:
1
Every PHI table has RLS on
And the policies tie each row to the user or the care team, with no policy that simply returns true.
2
The service role key stays on the server
That key skips RLS entirely. If it's in front-end code or a public environment variable, every rule above is decoration.
3
Storage buckets are private with policies
Uploaded documents sit behind the same access rules as the rows that point to them.
4
Access to PHI leaves a trace
Who read which record and when, written somewhere the app can't edit. Connection logging alone doesn't tell you which patient record was opened.
Our HIPAA checklist for AI-generated code goes through the rest, and why vibecoded healthcare apps fail HIPAA audits covers the failures we see past the database.
A short list to run through before real PHI goes in. If you can tick every line, you're in a defensible place. If you can't, you know what to fix first.
Supabase can be used for PHI if your organization is on the Team plan or higher, buys the HIPAA add-on, signs Supabase's Business Associate Agreement, and configures each project that holds PHI as high compliance. Free and Pro plans can't sign a BAA. Supabase also says its HIPAA controls aren't supported out of the box in self-hosted Supabase. A BAA covers Supabase's side; your app, your settings and your other vendors are still your responsibility.
No. Supabase's shared responsibility model says you need to be at least on the Team plan to sign a BAA, and the HIPAA add-on has to be enabled on the organization. The Team plan is listed from $599 a month on Supabase's pricing page, and the HIPAA add-on is a separate paid item.
Vercel signs BAAs with eligible Pro and Enterprise customers. Pro teams buy the HIPAA BAA add-on from billing settings, listed at $350 a month in Vercel's pricing docs; Enterprise teams request it through sales. Secure Compute, which gives isolated networking and dedicated IPs, is Enterprise only. Vercel's own guide says a BAA supports your compliance and doesn't guarantee it.
The code Lovable writes can run on infrastructure that is covered by BAAs, but Lovable's data processing agreement has customers agree not to provide PHI, and its security pages don't mention a BAA as of 2 October 2026. Lovable Cloud, the built-in backend, is run by Lovable, so PHI shouldn't be stored there unless you have a separate written agreement with Lovable that permits it. To hold PHI, connect your own Supabase organization on Team or higher with the HIPAA add-on, or move PHI to a separate backend that is covered, and keep PHI out of the Lovable editor and chat.
Usually not. Most AI-built apps keep their front end and their non-PHI data. The work is moving PHI to a covered backend, fixing row level security and storage rules, replacing services that see PHI without a BAA, and adding audit logging. An audit of the codebase tells you which parts stay and which move.
If you have a Lovable, Bolt or Cursor app on Supabase and Vercel and real patients are next, our vibe code rescue service starts with an audit of the code and the settings, and we don't rebuild what already works. For the wider picture of how we build for healthcare, see HIPAA app development.
NEWSLETTER
[ WRITTEN BY ]
Petar Jovanović
Co-Founder & Technical Lead
Co-Founder and Technical Lead at Oktopeak. Builds regulated software for legal and healthcare teams, and leads the rescues of codebases other vendors left half-finished.
[ VIBE CODE RESCUE ]
HEALTHCARE DEVELOPMENT
Mar 31, 2026
The default Lovable and Bolt setup has no path to a BAA: Lovable's DPA bars PHI, and the Supabase and Vercel plans a prototype starts on sign none. Here's what's missing from vibecoded healthcare apps, which plans do sign a BAA, and the path to production.
Read ArticleHEALTHCARE
Mar 31, 2026
AI tools generate functional code, not compliant code. This HIPAA checklist covers encryption, audit trails, access controls, PHI handling, and BAAs -- with real project data from rescue engagements.
Read ArticleHEALTHCARE
Aug 27, 2026 · 10 min read
Four parties sit in the BAA chain of an AI healthcare app: the covered entity, your app as business associate, the cloud, and the model provider. The model provider signs on API and enterprise tiers under conditions, and on none of the consumer plans. Vendor terms verified 27 August 2026, the mistake we made on a June call, and the architecture that needs fewer signatures.
Read Article[ GET STARTED ]
30-minute call. No pitch deck. Just an honest conversation about your project.
