HIPAA Compliant App Hosting 2026:Which Clouds Sign a BAA

"We're on Vercel and Supabase. Both say HIPAA on their websites. So we're covered, right?"

That's a paraphrase of the most common question I get from founders building a healthcare app, and the answer is almost always: not yet. Both companies will sign a business associate agreement. Neither one will sign it on the free plan, neither one covers every product it sells, and neither one covers the chat widget, the error tracker or the AI API your app quietly sends patient text to.

So I spent today, September 29, 2026, on sixteen vendor pages. The three hyperscalers, the developer platforms most small healthcare teams actually deploy on, and the services that sit behind them: database, messaging, AI. For each one I recorded whether it signs a BAA, how you get it, what plan it takes, and what the vendor itself says stays on you.

Here's the short version. Every major cloud signs a BAA. Most developer platforms do too, but only above a plan line, and three of them publish a price for crossing it: Vercel lists $350 a month on Pro, Supabase puts its HIPAA add-on on a $599 a month Team plan with the add-on itself priced privately, and Render adds 20 percent to everything you run. The rest ask you to talk to sales.

If you're still choosing who builds the app, the ranking of healthcare app development companies is the place to start. This article is about where the app lives once it exists.

The belief a competent person holds is reasonable: HIPAA compliance is a property of a vendor. Some hosts are HIPAA compliant, some aren't, and you pick one that is.

It doesn't hold, for two reasons the vendors themselves state.

First, there's no such certification. AWS says on its HIPAA page that there is no HIPAA certification for a cloud service provider. Google says there is no certification recognized by HHS for HIPAA compliance. Microsoft says the same about Azure. When a pricing page says "HIPAA," it means the company will sign a contract, not that some auditor stamped it.

Second, the contract is narrow on purpose. AWS lets you run any service in an account designated for HIPAA, but says PHI may only be processed, stored and transmitted in the services its BAA defines as eligible. Google tells customers to disable or avoid any product not explicitly on its covered list when working with PHI. Microsoft's BAA applies to in-scope services.

So the right model is a map, not a label. Draw every place patient data goes. Put a vendor next to each arrow. Then check three things per vendor: the BAA is signed, the specific product is on its list, and your plan is the plan the BAA requires. Any arrow without all three is an arrow you have to cut.

Think of it like a house insurance policy that names the rooms it covers. The policy is real. It just doesn't cover the shed you built last spring, and nobody will tell you that until the shed floods.

The regulator settled the main argument in 2016, and it's still the guidance teams get wrong most often.

The HHS Office for Civil Rights guidance on HIPAA and cloud computing says that a cloud provider which creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate is itself a business associate. That holds even when the data is encrypted and the provider has no key. HHS calls that arrangement a no-view service, and it doesn't get you out of the BAA. The Mintz summary of the guidance reads it the same way: lacking the key does not exempt the provider.

Why? Because encryption protects confidentiality, but the Security Rule also cares about integrity and availability. A host that can delete, corrupt or lose your encrypted database still holds your patients' records in every sense that matters to them.

I hear the conduit argument most about CDNs and edge networks. The logic runs: it's just passing bytes through. Maybe, for a pure transit path. But the moment a cache keeps a response with a patient's name in it, or a log line records a request body, that's storage. The safer default is to treat anything that can hold a copy as a business associate and get the BAA.

To be clear, I'm not a lawyer, and this isn't legal advice. It's how an engineering team should read a guidance document before it argues with its compliance counsel, not instead of that conversation.

All three sign. What differs is how you get the agreement and how you find out what it covers.

Most small healthcare teams don't start on raw AWS. They start on a platform that runs on top of one. That platform is a business associate in its own right, and it needs its own BAA regardless of what its cloud provider signed with it.

Every row below comes from the provider's own page on September 29, 2026, except where the row says otherwise. Where a vendor didn't publish a number, the cell says so. I didn't estimate any price.

How to re-check it: open the provider's HIPAA or compliance page and its pricing page, search for "BAA" and "HIPAA," and compare the plan you're on with the plan named. Screenshot both with the date. These pages change without notice, and the covered lists change most of all.

What I left out on purpose: security ratings, uptime claims and any "most secure" language. Those are the vendors' own claims about themselves, and a BAA table is not the place to launder them into facts.

The host is usually the easy BAA. The leaks happen one hop further out.

A typical clinic app I scope sends data to at least five places besides the host: a database, an SMS provider, an email provider, an e-signature tool and, now, an AI model. Each one needs its own BAA or a design that keeps PHI away from it.

The ones nobody lists are the quiet ones. Error trackers that capture request bodies. Session replay tools. Analytics pixels on a logged-in page. A support chat widget that sees whatever the patient types. Any of them can receive PHI without a single line of your code intending it to.

Every vendor I checked uses the phrase shared responsibility. Here's what that means in practice, split the way I explain it to clients.

Notice the shape. The vendor handles the building. You handle who has keys to which room, what gets written on the whiteboard, and who you let in through the side door.

This is also why a security review before launch pays for itself on a healthcare app. The things that fail are rarely the host. They're an open table, a debug log, a forgotten SDK. That's what a security audit should be looking for, and it's the same list I'd run through on a vibe-coded healthcare app that suddenly has real patients.

With the table in hand, the choice usually comes down to where your team already is, not which vendor is "most compliant." They all put the same burden on you.

If you have a small team shipping a Next.js app, Vercel plus Supabase is the shortest path, because both publish a self-serve or near self-serve route to a BAA and you can see most of the cost before a sales call. The trade is that you're paying two platform margins on top of the AWS they both run on, and one of the two prices is private.

If you have someone who likes infrastructure, going straight to AWS, Google Cloud or Azure is cheaper per unit and the BAA costs nothing extra on the face of it. The trade is labor. You now own the network, the IAM policy, the backups and the log pipeline, and every one of those is a place PHI can leak. A platform bundles some of that work into its price; a hyperscaler hands it to you.

If you already live on Heroku or Netlify for your marketing site and want the app next to it, expect an enterprise conversation. That's not a bad thing, but budget time for procurement. A sales-led BAA runs on the vendor's timeline, not yours, so start that conversation before you fix a launch date.

And if your app is Firebase today, the question isn't whether to leave Google. It's which Firebase pieces you swap for their covered Google Cloud counterparts before patient data arrives.

One more thing people skip. Ask each vendor how it notifies you of a breach and on what timeline, because the BAA will say, and you'll need that clause to meet your own notification obligations. Ask how you get your data out, in what format, and whether it deletes backups when you leave. Those three answers tell you more about a vendor's maturity than any badge on its homepage.

Mobile apps add a wrinkle. The phone itself is outside every hosting BAA, so anything cached on the device, pushed in a notification or stored in a crash report is your problem, not your host's. Keep PHI out of push notification text and crash payloads, and treat on-device storage as something you encrypt and expire deliberately.

This is a scenario, not a client. Say you're a two-location practice launching a patient portal: web app on Vercel, database on Supabase, a handful of staff and developers. What does the BAA layer add, using only published prices?

Vercel: a Pro team plus the $350 a month BAA add-on. Supabase: the Team plan at $599 a month, plus the HIPAA add-on, which isn't published, plus the compute add-on point in time recovery needs. So the published floor is $350 plus $599, about $949 a month, before seats, usage and the Supabase add-on you have to ask for.

Over a year, that's $949 times 12, about $11,400, as a known minimum. The honest total is higher, and you won't know by how much until Supabase quotes.

Now the same app on Render. Say your non-HIPAA usage would run about $600 a month. The 20 percent surcharge makes that about $720, so HIPAA costs you roughly $120 a month in surcharge, on top of whatever the Scale plan costs. On a bigger app the math flips: at $5,000 a month of usage the surcharge is $1,000 a month.

Is that a lot? Compare it to the build. A regulated healthcare build with us typically runs $180k to $420k+ over 14 to 24 weeks. A year of the Vercel plus Supabase floor is about 3 to 6 percent of that range. It's real money for a practice, but it's not the number that decides the project.

The clearest example I can give is our own. We built Zero Front Desk for Wisdom Tooth Clinic in Miami, the oral surgery practice of Dr. Peter K. Cudjoe. It's a bilingual English and Spanish voice agent on Retell AI, plus scheduling and intake behind it.

The hosting map looked like the one I described above, drawn before we wrote much code. Supabase with the HIPAA add-on, and row-level security from the very first migration, not bolted on later. Vercel Pro under a BAA for the app. OpenAI under a BAA for the one place a model touches intake, where it only summarizes, with the patient's name stripped first.

The clinical judgment isn't in the model at all. Intake red flags (bisphosphonates, anticoagulants, cardiac history, sedation risk) are deterministic TypeScript. The scheduling agent books through signed, opaque offer tokens, so it can't invent a slot. The call plays a recording and AI disclosure before any speech recognition starts, because Florida requires all-party consent.

The part most relevant to hosting is the CI. We run PHI scanning in CI as one of nine custom gates, alongside copy, contrast, schema, accessibility, crawlers, JS budget, agent rules and retention. A BAA can't stop a developer committing a test fixture with a real patient in it. A gate can.

Two things went wrong that belong in any honest write-up. We found 47 booking links pointed at a hostname with no DNS, fixed them, and added a check that every booking hostname resolves. And prompts drifted in the vendor console, so we moved them into the repo, versioned like code. Neither was a HIPAA failure, but both were the kind of drift that turns into one.

It went from first commit to live booking in 31 days. The performance numbers on that project are targets, not results, so I don't report outcomes here. The rest of our healthcare work is on the healthcare industry page.

You'll read in several places that HHS has finalized a big overhaul of the Security Rule. It hasn't.

HHS published a proposed rule on January 6, 2025. According to McDermott's read of the 2026 Unified Agenda, released in July 2026, HHS moved it to long-term actions with final action projected for July 2027, pushed back from an earlier May 2026 target. Agenda dates are estimates, not commitments.

So the 2003 Security Rule, as amended, is what governs your hosting today. The proposal would, among other things, make encryption and multi-factor authentication explicit requirements and change what BAAs must say.

My advice is to build as if the proposal might land, without claiming it has. Encryption everywhere, MFA for anyone with production access, an asset inventory you can actually produce. None of that is expensive on a new app, and all of it is expensive to retrofit.

Here's where the approach I'm recommending can go wrong, and what to watch for in a vendor or a developer.

• "We're HIPAA certified": There is no HIPAA certification for a cloud provider. AWS, Google and Microsoft all say so. A vendor claiming one is either careless with words or hoping you are.
• A BAA available but not signed: Available on the Enterprise plan is not the same as signed on yours. Ask for the countersigned copy.
• A product that isn't on the list: The BAA exists, but the specific database, auth service or AI endpoint you use isn't covered. Firebase Authentication is the textbook case.
• Logs and observability left out: Request logging, error tracking and session replay can all capture PHI. Each needs a BAA or scrubbing before data leaves your app.
• Plan downgrades: Someone downgrades a plan to cut costs and the BAA quietly stops applying. Put the plan requirement in your runbook.
• No migration path: Render's HIPAA upgrade is irreversible. Others lock you to a plan tier. Know what leaving would take before you commit.

The worst case of doing this properly is that you overpay for a tier for a few months before PHI arrives. That's a bounded, small loss. The worst case of doing it late is a reportable breach on an uncovered service. The bet is lopsided, which is why I push teams to sign before launch rather than after.

If your app also pulls records from an EHR, the integration layer brings its own agreements. That's the kind of boundary our API development work draws deliberately, so the PHI-carrying calls stay on covered services.

What I couldn't verify, stated plainly.

Oracle's own pages blocked my reader, so the Oracle row is marked not verified. HHS's site also blocks automated readers; I relied on its URL plus a law firm's summary of the same guidance. Cloudflare's only first-party source I could fetch is a 2020 blog post. Netlify's announcement date didn't parse cleanly, so I don't print one.

Several numbers I chased and dropped. A search summary claimed Render's HIPAA plans start at a specific monthly price; Render's own doc page didn't say that, so it's not here. Third-party blogs say Twilio excludes SendGrid from its BAA and that OpenAI answers BAA requests within a day or two; neither appeared on the vendors' pages I fetched. And a widely repeated line that HHS has already finalized the Security Rule overhaul is simply wrong.

Finally, this is a snapshot. Plans, prices and covered lists change. The date is on every row for a reason.

1. 1.Draw the map. Every place patient data goes: host, database, auth, storage, logs, email, SMS, AI, analytics, support chat. One arrow per vendor.
2. 2.Check each arrow for three things: a signed BAA, the exact product on the vendor's covered list, and your plan matching the plan the BAA requires. Screenshot the list with today's date.
3. 3.Cut or fix every arrow that fails. Upgrade the plan, move to a covered product, scrub the data before it leaves, or remove the tool. Then add a CI check so it stays fixed.

Time to get to work.