{"slug": "is-lovable-hipaa-compliant-not-by-default", "title": "Is Lovable HIPAA Compliant? Not by Default", "summary": "An analysis of Lovable's terms and security documentation found that the AI app builder is not HIPAA compliant by default: its terms prohibit uploading protected health information unless a plan or separate written agreement expressly permits it, its security page covers SOC 2 and GDPR but not HIPAA, and no Business Associate Agreement was offered on lovable.dev as of November 12, 2026. Because Lovable Cloud's Supabase project belongs to Lovable's organization rather than the customer's, users cannot sign a BAA with Supabase or enable its HIPAA add-on for that project. The recommended architecture keeps Lovable connected only to a development project with fake data while real PHI lives in a separately owned Supabase organization with a signed BAA and the High Compliance setting enabled.", "body_md": "No. Out of the box, Lovable is not a place to put protected health information, and Lovable says so itself. Its [terms](https://lovable.dev/terms) (last updated August 28, 2026) say that unless your plan or a separate written agreement \"expressly permits it\", you agree not to upload \"any protected health information subject to HIPAA\". The [security page](https://lovable.dev/security) talks about SOC 2 and GDPR and doesn't mention HIPAA at all, and we couldn't find a Business Associate Agreement offered anywhere on lovable.dev when we checked on November 12, 2026.\n\nSo the honest answer to \"is Lovable HIPAA compliant\" is: Lovable the builder isn't something you can make compliant on a normal plan. Your *app* can be, if you build it right and the PHI never goes near Lovable.\n\nThat's the part people get wrong. They ask about Lovable as if it were one thing. It's at least three: the AI editor that writes your code, the hosting that serves the frontend, and Lovable Cloud, which is the database, auth, storage and edge functions. HIPAA cares about every place PHI is stored or passes through, and each of those vendors needs to sign a BAA with you if it touches the data.\n\nLovable Cloud runs on Supabase, and Supabase does sign BAAs. That sounds like a loophole. It isn't.\n\nOn Lovable Cloud, the Supabase project belongs to Lovable's organization, not yours. You can't sign a BAA with Supabase for a project you don't own, you can't turn on Supabase's HIPAA add-on for it, and Lovable's terms say you shouldn't be putting PHI in there anyway. SOC 2 doesn't fix this either. A SOC 2 report says a vendor's own controls were audited. It isn't a BAA and it doesn't make your app compliant.\n\nAnd then there's the AI. When your Lovable project is connected to a database, the agent can read the schema and run SQL against it while it debugs. Great for building. Not great when the rows are patient intake forms.\n\nThe setup we'd use, and have used for a client in the clinic-scheduling space, has a hard line down the middle. Lovable keeps building the app. The real patient data lives somewhere Lovable never sees.\n\nFirst, the database moves to your own Supabase organization. Per Supabase's [HIPAA docs](https://supabase.com/docs/guides/security/hipaa-compliance), you sign a BAA with them, enable the HIPAA add-on, then mark the production project \"High Compliance\" in its settings. The add-on is available on Team and Enterprise only, per the [pricing page](https://supabase.com/pricing); Team starts at $599 a month, and the add-on price isn't published, so you get it from their sales team. Free and Pro can't do it.\n\nHigh Compliance turns on checks you have to keep passing. The [HIPAA projects guide](https://supabase.com/docs/guides/platform/hipaa-projects) lists point-in-time recovery (from $100 a month for 7 days), SSL enforcement, network restrictions and Postgres connection logging. If one of them gets switched off, the Security Advisor flags it. Self-hosted Supabase is explicitly out of scope for any of this, so \"we'll just run it on our own server\" doesn't get you there either.\n\nYou also want two Supabase projects, not one. Lovable stays connected to a development project full of fake patients. Production is a separate project that Lovable has no credentials for. Migrations go from dev to prod through the Supabase CLI or GitHub Actions, never by pointing the Lovable agent at production. This is the bit founders push back on, because it's slower, and it's the bit that matters most.\n\nThe frontend host needs a look too. If the app is a plain single-page app, the browser talks to Supabase directly and the host only serves JavaScript. But newer Lovable projects use TanStack Start with server functions, and code running on the server can see PHI on its way through. Either keep PHI out of server functions or host the app somewhere that will sign a BAA. Your email provider, your error tracker (session replay on a patient form is a breach waiting to happen) and your analytics all go on the same list.\n\nEven with every BAA signed, the app itself has to behave. Row level security on every table holding PHI, written so a patient can only read their own rows and staff only their clinic's. No PHI in URLs or query strings, because those end up in logs. Audit logging of who read what. Session timeouts. MFA for staff accounts.\n\nLovable's generated RLS policies are the usual weak spot. We reviewed one intake app where every policy was `auth.uid() IS NOT NULL`, meaning any logged-in patient could fetch any other patient's records through the API. The UI only showed your own, so nobody noticed. That's not a HIPAA technicality, that's a breach.\n\nNone of this is legal advice, and a covered entity still needs its own risk assessment and policies. But the technical side comes down to three questions for every piece of the stack: does it touch PHI, is there a BAA, and is it configured the way the BAA assumes.\n\nDon't load real patient data into it, and if you already have, talk to whoever handles compliance for you before anything else. Then move the backend out. Our [Lovable Cloud to Supabase migration](https://lovable2live.com/cloud-to-supabase/) moves everything to your own Supabase project in 1 to 2 days, from $150, and once it's in your organization you can sign the BAA and turn on High Compliance. A [security audit](https://lovable2live.com/lovable-security-audit/) of the RLS policies is $350. If you want the dev/prod split and the deploy pipeline set up as well, that's [taking the Lovable app to production](https://lovable2live.com/lovable-to-production/), from $500.\n\n*Originally published on [lovable2live.com](https://lovable2live.com/blog/lovable-hipaa/). Aakash Verma, software developer and founder of Lovable 2 Live.*", "url": "https://wpnews.pro/news/is-lovable-hipaa-compliant-not-by-default", "canonical_source": "https://dev.to/batmanofweb/is-lovable-hipaa-compliant-not-by-default-1kol", "published_at": "2026-11-14 23:47:14+00:00", "updated_at": "2026-11-14 23:53:04.111396+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "ai-policy"], "entities": ["Lovable", "Supabase", "HIPAA", "SOC 2", "GDPR", "TanStack Start", "GitHub Actions"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/is-lovable-hipaa-compliant-not-by-default", "markdown": "https://wpnews.pro/news/is-lovable-hipaa-compliant-not-by-default.md", "text": "https://wpnews.pro/news/is-lovable-hipaa-compliant-not-by-default.txt", "jsonld": "https://wpnews.pro/news/is-lovable-hipaa-compliant-not-by-default.jsonld"}}