Short answer: Bolt.new is not HIPAA compliant, among the vibe-coding tools not built for regulated health data. Bolt (built by StackBlitz) offers no Business Associate Agreement anywhere in its Terms of Service, Privacy Policy, Enterprise page, or Pricing page. What makes Bolt’s paper trail unusual is the split between documents: its Terms of Service haven’t been updated since January 10, 2024 — before Bolt existed in its current AI app-builder form — and never mention AI, prompts, or PHI at all. The only document that actually addresses AI data handling is the separately maintained Privacy Policy (last updated May 12, 2026), which tells users plainly not to submit health information in prompts, code, or uploaded files.
- Gil Vidals, HIPAA Vault’s CTO, directly named Bolt.new alongside Cursor, Replit, and v0 in Episode 107 as vibe-coding platforms not built for HIPAA compliance: “I don’t believe these building platforms offer HIPAA compliance. I don’t think that’s their forte.”
- Bolt’s Terms of Service is dated January 10, 2024 and never mentions AI features, prompts, models, or PHI — the AI-specific data handling only appears in the separately versioned Privacy Policy (updated May 12, 2026).
- That Privacy Policy explicitly lists health information as “sensitive personal information” Bolt says it doesn’t intentionally collect, instructing users directly not to submit it in prompts, code, or uploaded files — a softer, GDPR/CCPA-style framing rather than a HIPAA-specific prohibition.
- Bolt’s default backend, “Bolt Database,” is actually a Supabase project Bolt manages on your behalf — and Bolt provides a documented “Claim your Bolt Database in Supabase” feature to move ownership of that underlying project into your own Supabase account.
- No BAA, SOC 2 attestation, or HIPAA program is mentioned anywhere across Bolt’s Terms, Privacy Policy, Enterprise page, or Pricing page.
Ready to move your Bolt.new-built app to a compliant environment? HIPAA Vault handles the architecture audit, the remediation work, and the deployment to a BAA-covered environment.
Book a Free Architecture Consultation → | Talk to a specialist →
Does Building in Bolt.new Involve PHI?
Bolt is a full application builder with built-in hosting and a database layer, not just a code editor. PHI risk during a Bolt build shows up in a few specific places:
- Prompts and chat context — describing real patient scenarios, or generating a Discussion Mode summary of a conversation that references real records to preserve context across projects.
- Uploaded or attached files — Bolt’s Privacy Policy specifically addresses files attached to a project, prompt, or conversation; relevant portions can be transmitted to third-party AI providers when explicitly attached to a prompt.
- Bolt Database or a connected Supabase project — whichever backend a project uses, it’s a live, hosted data store the moment it’s provisioned, not a local test database.
- Published or hosted projects — once a project is published to bolt.host, a custom domain, or Netlify, whatever data the app holds is live in production.
Technical Clarification on WebContainers: While WebContainers execute Node.js locally inside your browser, your prompts and uploaded context are still sent over the wire to third-party LLM providers (like Anthropic) to generate the code. Local runtime execution does not equal local prompt processing.
If none of the above touches real patient data, Bolt functions as a reasonable prototyping sandbox. The moment actual PHI enters any of those four surfaces, there’s no BAA in place to cover it
Bolt.new’s Security Posture vs. What HIPAA Requires
| Security control | Bolt's current posture | Does this satisfy HIPAA? |
|---|---|---|
| Health/PHI data policy | Privacy Policy: "does not intentionally collect or process" health information; tells users not to submit it in prompts, code, or files | Descriptive disclaimer, not a contractual ban — and still no BAA |
| Governing Terms of Service | Last updated January 10, 2024; predates Bolt's AI product entirely — no mention of AI, prompts, or PHI anywhere | The contract users agree to doesn't address how the product actually handles data |
| Compliance certification | Not stated in Terms, Privacy Policy, Enterprise page, or Pricing page | No SOC 2 or similar certification claimed |
| Data training | AI Inputs/Outputs may be used to improve the Services on an "aggregated, anonymized, or de-identified" basis; opt-out availability varies by plan | Vague, plan-dependent |
| Backend infrastructure | Default "Bolt Database" runs on Supabase under the hood; users can also connect or "claim" their own Supabase project directly | Third-party subprocessor either way, no HIPAA path stated |
| Runtime architecture | WebContainers: browser-sandboxed Node.js runtime, no per-project VM | Different attack surface, not a compliance framework |
| Enterprise access controls | SSO (SAML, Okta, Azure AD, GitHub, GitLab), admin portal, audit logs on Enterprise plan | Good practice, not HIPAA-specific |
| BAA available? | Not mentioned anywhere across Terms, Privacy Policy, Enterprise, or Pricing pages | Required for PHI — currently absent |
Verified against Terms of Service (last updated January 10, 2024), Privacy Policy (last updated May 12, 2026), Enterprise, and Pricing as of July 2026. Vendor terms and security posture change — confirm current BAA availability directly with StackBlitz before relying on this for a live HIPAA program.
A Terms of Service That Predates the Product
StackBlitz’s Terms of Service — the legal agreement that actually governs Bolt.new use — is dated January 10, 2024, and reads like a generic web-IDE agreement: a license to use “the Services,” paid-plan billing terms, restrictions on scraping and reverse engineering, a copyright policy. There isn’t a single clause about AI, prompts, model providers, or AI-generated code anywhere in it.
The AI-specific data handling commitments — what happens to prompts, how AI Inputs and Outputs are used, the health-data language — all live in a separate document: the Privacy Policy, last updated May 12, 2026. That’s a meaningfully more current, more detailed document, but it’s also unilaterally updatable independent of the Terms, and it isn’t the contract users formally accept when they sign up. For a compliance review, that split matters: don’t assume the Terms of Service covers what the AI actually does with your data. It doesn’t mention AI at all. Check the Privacy Policy separately — and note that neither document offers a BAA.
Your AI Prototype Works. Is It Ready for Healthcare?
HIPAA Vault reviews your architecture, addresses compliance gaps, and deploys your application into secure, managed infrastructure.
Book a Free 15-Minute ConsultationWhat the Privacy Policy Actually Says About Health Data
Bolt’s Privacy Policy addresses sensitive data directly, under a section on information collected:
“Bolt does not intentionally collect or process special categories of personal data (such as health information, biometric data, precise location data, or government-issued identifiers). Users should not submit sensitive personal information in prompts, code, or uploaded files.”
This is a real, current statement — but it’s worth comparing to how a peer platform handles the same disclosure. Lovable’s Terms of Service create an affirmative contractual prohibition: “You agree not to upload… protected health information under HIPAA.” Bolt’s language is descriptive rather than a signed agreement not to, frames the issue in general privacy-law terms (the “special categories” language comes from GDPR/CCPA, not HIPAA), and never names HIPAA specifically. Practically, the outcome lands in the same place — no BAA, no PHI — but the strength of the underlying commitment differs, and that’s a distinction worth knowing before treating either statement as a compliance guarantee.
The same Privacy Policy also includes a direct security reminder relevant to any healthcare builder: “Do not include secrets, API keys, passwords, or confidential information in prompts, source code, or publicly shared content.” Published or shared Bolt projects are, by default, things other people can see — a detail that matters as much for credentials as it does for patient data.
What Gil Vidals Says About Vibe Coding Platforms and HIPAA
On the HIPAA Insider Show, Gil Vidals named Bolt.new specifically as one of the platforms healthcare builders are using to vibe-code applications before running into a compliance wall:
“Some of those platforms that are being used for the vibe coding — to mention a few — Cursor, Replit, Bolt.new, v0… That sandbox area is a fantastic place to develop it, but you have to find a home for your application. I don’t believe these building platforms offer HIPAA compliance. I don’t think that’s their forte.”
On why the AI layer itself can’t close that gap:
“At this juncture, AI is trapped in the virtual world. It does everything inside the computer — it’s digital. To be HIPAA compliant, you have to touch the physical world. The AI doesn’t do that yet. That means you have to have infrastructure that’s HIPAA compliant… and even if that infrastructure is configured, the code itself is probably going to live on a virtual machine, and that virtual machine has to be configured to be HIPAA compliant too. You have to monitor it, scan it, run vulnerability reports, patch it on a weekly or monthly basis.”
(Source: HIPAA Insider Show, Episode 107, “Vibe Coding to HIPAA-Compliant Production: The Steps.”)
From Bolt.new to Production: The Migration Steps
Bolt’s architecture gives it a genuinely different migration path than a tool like Cursor or Lovable, largely because of how its database layer works:
- Determine your actual backend first. A Bolt project either uses the built-in “Bolt Database” or a connected Supabase project — this determines your data path entirely.
- If you’re on Bolt Database, claim it into your own Supabase account before doing anything else. Bolt’s Advanced database settings include a “Claim your Bolt Database in Supabase” feature specifically for this. Note that Bolt is explicit there’s “no supported flow for migrating Supabase databases to Bolt databases” — once you claim into Supabase, that’s the direction you’re moving, with no path back.
- Test thoroughly with a second reviewer before export. Gil’s guidance applies here as much as anywhere: “Don’t just make it and then try to ship it out. Make sure you review it.”
- Download the application code. Bolt’s documented export path is project title → Export → Download, which produces a zip file of the codebase.
- Treat any real PHI in the exported code or claimed database as PHI in transit — use a secure transfer method, not a casual download and email.
- Confirm your new host — or Supabase’s own compliance program, evaluated separately — will sign a BAA before go-live. As Gil puts it: “One of the first questions you want to investigate is: do they support signing a BAA? If they say yes, then at least you got past that point.”
- Revisit AI feature usage in production. Prompts still transit third-party AI providers per Bolt’s Privacy Policy; confirm that path is accounted for if the live app keeps AI features active.
Your AI Coding Tool Is Only One Layer
Bolt.new can take a healthcare founder from a prompt to a working, hosted application remarkably fast. None of that changes what has to be true before real patient data touches it: hosting infrastructure with its own signed BAA, encrypted storage and transmission under that agreement, access controls, audit logging, and a documented risk analysis. As Gil Vidals puts it, HIPAA compliance “is not a one and done” — it’s an ongoing commitment at the infrastructure level that a builder tool, however capable, isn’t positioned to satisfy on your behalf.
HIPAA Vault has provided that infrastructure layer since 1997, with certifications including NIST 800-53, SOC 2 (AICPA), HITECH Omnibus, and GSA. Whatever tool built the app, it still needs a compliant home to run in.
Ready to move your Bolt.new-built app to a compliant environment? HIPAA Vault provides fully managed cloud hosting with a signed BAA.
View hosting options → | Talk to a specialist →
Questions to Ask Before Moving a Bolt.new-Built App to Production
- Is your project on Bolt Database or a connected Supabase project? This determines whether you need to claim the database into Supabase first, and shapes your entire migration path.
- Has any real PHI been entered into prompts, uploaded files, or the database at any point? Bolt’s Privacy Policy says this shouldn’t have happened — confirm it didn’t.
- Will your hosting provider sign a BAA? If not, it’s disqualified for any workflow touching PHI, regardless of how the app was built.
- Are secrets or API keys hardcoded anywhere in the exported code or a publicly shared project? Bolt’s own Privacy Policy flags this as a real risk, not a hypothetical one.
- If the production app still calls an AI model, which provider, and under what agreement? Confirm that path is covered before go-live.
Frequently Asked Questions
This article is educational and does not constitute legal advice. Consult a qualified HIPAA compliance attorney for guidance specific to your organization. Vendor terms and security posture reflect StackBlitz’s Terms of Service (dated January 10, 2024), Privacy Policy (dated May 12, 2026), Enterprise page, and Pricing page as of July 2026 — verify current terms directly with StackBlitz before relying on this for a live HIPAA program.


