A client rang me on a Thursday afternoon in late 2023 -- fintech-turned-healthtech pivot, they'd just hired a compliance consultant who'd looked at their Next.js codebase and handed back a three-page list of problems. "We thought putting it on AWS was enough," the founder said. He genuinely believed that. And honestly? I'd heard that same sentence from probably six different teams before his.
HIPAA compliance is one of those areas where everyone thinks they understand the surface -- sign a BAA, pick a compliant cloud provider, done. But the HIPAA Security Rule doesn't care about your hosting provider's marketing page. It cares about how your application handles, stores, transmits, and audits Protected Health Information (PHI). Next.js -- as a framework -- is neither compliant nor non-compliant out of the box. What you build on top of it is everything.
So let me walk you through what actually counts in 2026, based on real architectures I've built and real mistakes I've watched teams make.
---
The three real HIPAA paths in 2026 -- pick yours before you pick a stack
If you are building anything healthcare-shaped this year, you have three paths that actually compile to a signed Business Associate Agreement and a defensible audit trail. Most engineering blogs only cover the first one. The other two are cheaper, faster, and the right answer more often than the Next.js crowd admits.
- Path 1 -- Next.js + Vercel BAA: the right call when your product has authenticated dashboards, custom workflows, real-time data, AI features, or anything past static content. Vercel finally opened HIPAA BAAs to Pro teams in 2025 at a $350/month add-on, so you no longer need an Enterprise contract to ship.
- Path 2 -- WordPress on a HIPAA-eligible host: the right call when your healthcare site is a marketing site plus intake forms plus an editorial team that already knows wp-admin. Atlantic.Net signs a BAA from $350/month, Liquid Web from $600/month, HIPAA Vault for fully managed. The path most healthcare clinic sites should take.
- Path 3 -- JotForm Gold at $99/month: the right call when the only PHI you handle is forms -- patient intake, symptom check-in, feedback. JotForm includes HIPAA on the Gold plan with no add-on. PHI never touches your infrastructure. Embed the form, sign the BAA, ship in an afternoon.
The rest of the post covers the architecture decisions for path 1 in depth, but the Vercel BAA section, the WordPress section, and the JotForm section explain when each path is the right one. If you are about to read 2,000 words on Next.js audit logging when JotForm would have solved your actual brief in an hour, the next three minutes are the most valuable on this page.
What "HIPAA-Compliant Next.js" Actually Means
People confuse infrastructure compliance with application compliance. These are not the same thing.
Your cloud provider (AWS, GCP, Azure -- pick one) can sign a Business Associate Agreement with you. That's a legal document establishing they'll protect PHI on their infrastructure according to HIPAA rules. AWS has a HIPAA-eligible services list that's worth bookmarking. But a BAA from AWS doesn't mean your Next.js app is compliant. Not even close.
The application layer is your responsibility. Always. The framework is just a vehicle.
Here's the thing -- Next.js 14+ (and into 2026, the App Router is fully mature) gives you server components, server actions, middleware, and edge functions. Every single one of those has different PHI-handling implications. A server component that queries a patient database and passes data down to a client component -- where does that data live? How long? Does it end up in a browser cache? These aren't hypothetical concerns.
---
The PHI Surface Area Problem
Before writing a line of code, I make every health-tech client do one exercise: map every place PHI could possibly touch the application. Not where it should touch it. Where it could.
That includes:
- URL parameters (I've seen patient IDs in query strings -- don't)
- Browser
localStorageandsessionStorage - Client-side state management (Zustand stores, Redux, even React context)
- Next.js fetch cache and the Data Cache layer
- Log output from
console.logduring development that sneaks into production - Error tracking tools like Sentry (more on this shortly)
- Analytics pipelines -- GA4, Segment, Amplitude
The last two trip up more teams than almost anything else. Back in early 2024, Seahawk had a telehealth client who'd wired up Sentry for error monitoring. Standard move. Except their error boundaries were capturing the full props object on crash -- which included appointment details and user health flags. Sentry wasn't covered under their BAA. That's a breach waiting to happen.
Sanitising Your Error Tracking
If you're using Sentry with PHI-adjacent code, use the beforeSend hook to scrub sensitive fields before they leave the browser. Full stop. Something like this is non-negotiable:
``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``
Sentry does have a HIPAA compliance path -- they'll sign a BAA -- but you still need to configure what data you send them. The BAA doesn't sanitise your payloads automatically.
---
Authentication and Session Handling
This is where I see the most shortcuts. Teams reach for NextAuth.js (now Auth.js), wire up a provider, and call it done. Auth.js is a solid library. But the defaults are not HIPAA defaults.
A few specifics:
- Session token storage -- Auth.js defaults to a cookie-based session, which is fine, but you need
httpOnly,secure, andsameSite: 'strict'explicitly set. Don't assume. - Session expiry -- HIPAA's Automatic Logoff standard (§164.312(a)(2)(iii)) requires that sessions terminate after a defined period of inactivity. The number isn't prescribed, but 15 minutes is the industry standard for clinical applications. Wire up an inactivity timer in your layout. I usually build this as a custom hook that fires a server action to invalidate the session.
- MFA -- Not strictly mandated by HIPAA's text, but try explaining to an OCR auditor why you didn't implement it after a breach. Use TOTP via something like
otplibor lean on an identity provider like Auth0 or Clerk that has MFA baked in and will sign a BAA. - Audit logging of auth events -- Every login, failed login, and logout needs to be logged with a timestamp and user identifier. Every single one.
I'm not going to tell you Auth.js is wrong for this use case -- I've shipped it in production on HIPAA projects. But you have to layer the compliance requirements on top deliberately.
---
Data in Transit and at Rest
Transit is the easy part. TLS 1.2 minimum, TLS 1.3 preferred, everywhere. Not just your main domain -- your API routes, your edge functions, any webhooks. If you're on Vercel, this is handled. If you're self-hosting on EC2 or running Next.js in a Docker container behind an NGINX reverse proxy, you need to configure this yourself. I've reviewed codebases where the internal service-to-service calls were still on HTTP because "it's inside the VPC." That's not an acceptable position.
At rest is harder. A few specifics that matter:
- Database encryption -- AWS RDS with encryption enabled (uses AES-256 via AWS KMS). This is a checkbox, but you need to actually check it and document it.
- Field-level encryption for highly sensitive data -- For things like SSNs, diagnoses, or medication lists, I often add a second layer of encryption at the application level using a library like
@aws-sdk/client-kmsto wrap/unwrap keys. Overhead is real, but so is the risk. - Next.js Data Cache -- This one catches people out. The App Router caches fetch responses by default. If you're fetching patient data in a server component with
fetch(), you need{ cache: 'no-store' }unless you're very deliberately managing revalidation. A cached response containing PHI sitting in the server's memory or filesystem is a problem. - Backups -- Encrypted. Tested. Documented. Obvious, but I've audited systems where the backups existed but had never been restored once.
---
Audit Logging: The Part Nobody Wants to Build
Here's something I'll say plainly -- audit logging is the most boring and most important thing you'll build in a health-tech app. Every access to PHI needs to be recorded. Not just writes. Reads too.
The HIPAA Audit Controls standard(§164.312(b)) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." What that means practically: you need an append-only log of who accessed what patient data, when, and from where.
I build this as a middleware layer in Next.js. For App Router projects, I'll intercept in middleware.ts for route-level logging and add a thin service wrapper around any database query function that touches PHI tables. The log records get written to a separate database table (or a service like AWS CloudTrail if you want immutability guarantees) -- never the same table as the PHI itself.
A minimal audit record looks like this:
user_id-- whoresource_type+resource_id-- whataction-- read / write / deleteip_address-- where (anonymised at the network layer is fine)timestamp(UTC, always UTC)request_id-- to correlate with your application logs
Do not let developers add console.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Choosing Your Infrastructure Stack
The honest answer is that in 2026 there are a handful of stacks I'd actually recommend for a production HIPAA Next.js application.
Vercel + PlanetScale/Neon + Clerk is the developer-experience stack. Vercel will sign a BAA (enterprise plan -- yes, it costs money). PlanetScale and Neon both have HIPAA-eligible tiers. Clerk handles auth and will sign a BAA. This is fast to ship and reasonable to operate. The tradeoff is cost at scale and some loss of infrastructure control.
AWS (ECS/EKS for the Next.js app) + RDS Aurora + Cognito is the enterprise stack. More operational overhead. Much more control. AWS's shared responsibility model is well-documented and the BAA coverage is broad. If your client is a hospital system or an insurer, they're probably going to ask about your AWS architecture in detail.
Render or Railway -- I'd steer clear for anything seriously regulated. They're great tools, but their HIPAA compliance story is thin.
One thing I want to flag: Vercel's Edge Network and Edge Functions are not HIPAA-covered under their BAA as of early 2026. If you're running logic that touches PHI in edge middleware, that's a gap. Run that logic in serverless functions (Node.js runtime) instead.
---
Vercel's HIPAA BAA -- what $350/month actually buys you
Until 2025, signing a Vercel BAA required an Enterprise contract -- typically around $45,000 per year at the median spend. That priced most pre-Series-A health-tech teams out and pushed them onto AWS or Cloudflare instead. In 2025 Vercel changed that: HIPAA BAAs are now available as a self-serve $350/month add-on on the Pro plan.
The Pro BAA is a click-through agreement, signed via the Vercel dashboard. There is no negotiation, no minimum commit, no Enterprise sales call. If you are on Pro at $20/seat/month and you add the HIPAA add-on, your team-of-three healthcare app is at $410/month all-in for the platform layer.
What the Pro BAA covers
- Vercel acts as your business associate for HIPAA purposes -- they have the technical and organisational safeguards a covered entity needs in a vendor.
- Annual third-party audits, breach notification within HIPAA timelines, and the standard suite of administrative safeguards.
- Edge runtime, Functions, ISR, image optimisation, and the rest of the Vercel platform are in scope under the BAA.
What the Pro BAA does NOT cover -- read this before you commit
Vercel's enhanced security feature -- Secure Compute -- is Enterprise-only. Secure Compute gives you isolated cloud networks, dedicated IP addresses, and VPC peering. If your security architecture requires network isolation between your app and the public Vercel infrastructure (a fair ask if your auditor cares about defence-in-depth), the Pro BAA is not enough. You need Enterprise.
Practical translation: the Pro BAA at $350/month works for most early-stage healthcare apps where the audit posture is appropriate-controls-based. If you are selling into hospital systems or you have a compliance officer who has read NIST SP 800-66 cover to cover, you will be on the Enterprise plan anyway.
If you also need SSO
SAML SSO on Vercel Pro is a separate $300/month add-on. Combined with the HIPAA BAA, you are at $650/month in compliance add-ons. That is roughly the threshold where the Enterprise quote starts looking comparable on TCO -- at $45K/year median, Enterprise prices out to about $3,750/month, but it folds in BAA, SSO, Secure Compute, dedicated support, and several other features. The math sits at year two for most teams.
The WordPress path most engineers never consider
If you have spent the last six weeks deciding which Next.js auth library has the best HIPAA story, here is a question to interrupt that thread: does your product actually need authentication? Or is the brief a marketing site, an editorial blog, and a HIPAA-compliant intake form?
If the answer is the second one -- and for most healthcare clinics, dental practices, mental-health providers, and physiotherapy clinics, the answer is the second one -- WordPress on a HIPAA-eligible host is the path you should be on. The cost is lower, the editorial workflow is solved, and the security model is genuinely simpler. Plugins are still the attack surface they have always been, but you can ship with a small plugin set and a managed HIPAA host that audits the rest.
Hosts that sign a BAA for WordPress
- Atlantic.Net -- managed HIPAA WordPress hosting from $350/month with a signed BAA, encrypted VPN access, daily backups, MFA, and a 100% uptime guarantee. Two decades of healthcare IT. The default pick for clinics.
- Liquid Web -- fully managed dedicated, VPS, or cloud from $600/month with HIPAA-aligned configurations and a signed BAA. Strong support, mature ops.
- HIPAA Vault -- purpose-built for HIPAA from day one. Higher price, deeper compliance posture, used by larger healthcare orgs.
- ScalaHosting -- managed VPS from $29.95/month with a signed BAA, daily backups, encrypted transfer. Cheapest end of the curve; suits early-stage, smaller traffic.
- AWS / Azure / GCP with managed WordPress on top -- every major cloud will sign a BAA, but you are responsible for configuration, hardening, and ongoing posture. Right answer if you already have a cloud team.
Where the WordPress path stops working
- Authenticated patient dashboards -- possible in WordPress, painful, and the plugin gap is real. Move to Next.js + Vercel BAA.
- Real-time data, AI features, custom workflows -- WordPress will fight you. Next.js + Supabase + Vercel BAA is the right call.
- Anything past 100 plugins or a complex membership system -- the plugin attack surface alone is a HIPAA risk worth designing out.
If your brief sits in the WordPress lane, the practical migration path is the headless WordPress option -- wp-admin for editors, a Next.js or Astro front end on the public side, WPGraphQL bridging the two. You keep the editorial workflow, the public site is fast, and the public surface gets the modern hosting story. Before you commit either way, the WordPress Stack Advisor takes your URL and tells you which path actually fits.
JotForm Gold at $99/month: when the shortcut is the right call
If the only PHI your product touches is what comes through a form -- patient intake, symptom check-in, post-visit feedback, appointment requests -- you do not need to build HIPAA-compliant forms in your application. JotForm Gold at $99/month per user includes HIPAA at no add-on cost. PHI is collected on JotForm's HIPAA-audited infrastructure and never touches your servers.
What JotForm Gold actually includes
- HIPAA compliance built in -- signed BAA via the JotForm dashboard, no upcharge.
- 100 forms, 10,000 monthly submissions, 100 GB storage. More than enough for a multi-location clinic.
- HIPAA-eligible field types: signature capture, file upload (encrypted), conditional logic, prefill, payment integrations with HIPAA-compliant processors.
- Embed via iframe on your WordPress site, your Next.js app, your Webflow page, anywhere. The form runs on JotForm's infrastructure; your site never sees the PHI.
- Workflow integrations with HIPAA-eligible CRMs, EHRs, and pharmacy platforms. The list is shorter than for non-HIPAA mode but covers the common pieces.
When JotForm wins on TCO
Building a HIPAA-compliant intake form natively in Next.js is a 2 to 3 week engagement: encrypted-at-rest database column, audit logging, BAA with your storage provider, security review, threat-model documentation, and the ongoing maintenance that goes with a custom form pipeline. JotForm at $99/month does it in an afternoon. If your form is the only PHI touchpoint, the math always favours JotForm.
Where JotForm stops being enough
- Your patient portal -- anything that needs to read back PHI from earlier interactions, render a patient timeline, or integrate deeply with your application data. Build it in your app.
- Branding constraints that demand pixel-perfect form UX. JotForm's customisation is good, not perfect.
- Multi-step clinical workflows that go past form-fill -- triage logic, real-time clinician chat, decision-support trees. Custom build.
- If your auditor wants every PHI byte to live inside your VPC. JotForm is the right call when delegating to a HIPAA-audited vendor is acceptable; it is the wrong call when your security model demands isolation.
Third-Party Integrations: Where Compliance Goes to Die
Every third-party you integrate with that touches PHI needs a BAA. That sounds obvious. Here's the list that actually trips teams up:
- Customer support tools (Intercom, Zendesk) -- if a patient messages about their health, that's PHI in your support platform
- Form tools (Typeform, Jotform) -- patient intake forms are PHI
- Email providers (SendGrid, Postmark) -- if the email body contains health info, BAA required
- Feature flag tools (LaunchDarkly, Statsig) -- usually fine, but if you're passing user attributes that include health status to evaluate flags, that's PHI
- CRMs (HubSpot, Salesforce) -- many healthtech teams sync patient data into these without thinking
Postmark will sign a BAA. SendGrid (via Twilio) will too, on paid plans. Twilio for SMS as well. LaunchDarkly has a BAA path. These aren't obscure options -- the BAA process is usually a form submission and a few business days.
The ones that won't or can't sign a BAA? Don't integrate them anywhere near PHI. Simple as that.
---
FAQ
What does Vercel's HIPAA BAA actually cost?
Vercel's HIPAA Business Associate Agreement is available on the Pro plan as a $350/month add-on, signed via a self-serve click-through in the dashboard. SAML SSO on Pro is a separate $300/month add-on, putting a typical compliance setup at $650/month combined. The Enterprise plan, which sits around $45,000/year at the median, includes the BAA, SSO, and Secure Compute (isolated networks, dedicated IPs, VPC peering).
Can I run a HIPAA-compliant WordPress site?
Yes, on a HIPAA-eligible host that signs a BAA. The four common picks in 2026 are Atlantic.Net (from $350/month), Liquid Web (from $600/month), HIPAA Vault (purpose-built for healthcare), and ScalaHosting managed VPS (from $29.95/month). The WordPress path is the right one for healthcare marketing sites, clinic sites, and editorial-heavy content. It stops working when you need authenticated patient dashboards, real-time data, or anything past 100 plugins of attack surface.
Is JotForm enough for HIPAA-compliant forms?
If forms are the only PHI touchpoint, yes. JotForm Gold at $99/month includes HIPAA at no extra cost -- signed BAA, 100 forms, 10,000 submissions, 100 GB storage. PHI is collected on JotForm's HIPAA-audited infrastructure, embedded via iframe on your site. JotForm stops being enough when your product needs to read PHI back across sessions, render patient timelines, or run multi-step clinical workflows.
When does the WordPress path beat the Next.js path for HIPAA?
When your healthcare product is a marketing site plus a blog plus an intake form. WordPress is faster to ship, cheaper to host, and the editorial workflow is already solved for non-technical staff. The Next.js path wins when you need authentication, custom dashboards, real-time data, AI features, or anything that benefits from a modern application architecture. A common hybrid: WordPress on a managed HIPAA host for the public site, Next.js on Vercel BAA for the authenticated app, JotForm for the intake form.
Does deploying on Vercel make my Next.js app HIPAA-compliant?
No. Vercel can sign a Business Associate Agreement on their enterprise plan, which means they take on certain HIPAA obligations for the infrastructure they control. But your application code, your database design, your logging, your third-party integrations -- none of that is covered by Vercel's BAA. Compliance is shared across every layer of the stack, and the application layer is your responsibility.
Do I need to encrypt data in a Next.js API route before sending it to the client?
TLS handles encryption in transit, so you don't need to manually encrypt the HTTP response body. What you do need to do is make sure you're only returning the minimum necessary PHI for the operation -- not full patient records when you only need a name, for instance. The "minimum necessary" principle is baked into HIPAA and it should shape your API response design from day one.
Is the Next.js App Router's built-in caching safe for PHI?
Not by default. The Data Cache and Full Route Cache in the App Router can cache responses that contain PHI, which is problematic. For any route or fetch call that touches patient data, use{ cache: 'no-store' }on fetch calls and add export const dynamic = 'force-dynamic'to route segments. Review Vercel's caching documentation carefully -- it's dense but important.
What's the minimum logging I need for a HIPAA audit trail?
At minimum: who accessed what, when, and from where. That's user ID, resource identifier, action type, timestamp, and IP address. Logs need to be tamper-evident (append-only, not editable by application code) and retained -- most compliance frameworks suggest six years, which matches HIPAA's documentation retention requirement.
Can I use React Query or SWR for data fetching in a HIPAA app?
Yes, but with care. Both libraries cache responses client-side, which means PHI can sit in the browser's memory. Set staleTime: 0 and cacheTime: 0(React Query) or dedupingInterval: 0(SWR) for queries that return PHI. Also clear the query cache on logout explicitly -- don't rely on component unmounting to handle this.
---
I want to be honest about something: HIPAA compliance is genuinely hard to get right, and no framework -- Next.js or otherwise -- makes it easy. The teams I've seen do it well are the ones who treat it as an architecture problem from day one, not a checklist to run through before launch. The framework is fine. The gaps are almost always in the decisions made around it.
Start with the PHI surface area mapping. Everything else follows from that.
Related reading
Hosting stacks that actually sign a HIPAA BAA in 2026 -- the deeper hosting comparison post, with annual cost ranges and BAA scope notes for each provider.
WordPress vs Next.js: when each is the right call -- the framework decision without the HIPAA framing, useful as the prequel.
Headless WordPress + Astro: a working setup -- if you take the WordPress path but want a modern public front end.
WordPress Stack Advisor -- paste your URL, get a tailored recommendation that includes the HIPAA path that fits your brief in 30 seconds.
If you are about to ship a healthcare product and you cannot tell which of the three paths above is the right one for your brief, the next thirty minutes will solve it.
Book a 30-minute HIPAA stack call -- you describe the product, I tell you whether the answer is Next.js + Vercel BAA, WordPress on a managed HIPAA host, JotForm, or a hybrid. By the end of the call you have a stack pick, a price range, and a migration path if you are already on the wrong stack.