Try Interactive Demo
No-code database platforms are transforming the way web apps are…
Template Marketplace
Use Knack’s Patient Portal Template to give patients, providers, and…
Knack’s Telemedicine App Template gives healthcare providers, clinics, and independent…
Knack’s Patient Intake Form Template helps healthcare teams digitally collect…

How to Connect a Bolt App to a HIPAA-Compliant Backend

  • Written By: Samantha Suser
Bolt HIPAA Backend- How to Connect Bolt to Knack Health

Bolt is one of the fastest ways to go from a healthcare app idea to a working interface. However, when you take that interface live with real patient data, you need a bolt hipaa backend that Bolt cannot provide on its own. Bolt does not sign a Business Associate Agreement, and its default Supabase-managed database does not cover the Bolt layer where your prompts are processed. This guide walks through exactly how to set up your bolt hipaa backend connection, step by step.

Key takeaways

  • Bolt does not sign a BAA and is not HIPAA compliant for applications that store or process PHI. Its default backend also lacks BAA coverage at the Bolt layer even if you claim the underlying Supabase project.
  • Connecting Knack Health as the bolt hipaa backend via Knack’s MCP server does not require rebuilding your Bolt frontend. The interface stays exactly as it is.
  • At build time, Knack’s MCP server gives Bolt’s AI visibility into your Knack data schema. At runtime, all PHI routes to Knack Health’s infrastructure via Knack’s API, never touching Bolt’s backend.
  • The setup takes minutes. You need a Bolt project, a Knack account, and a Knack Health HIPAA plan before any real patient data enters the system.
  • Build and test with placeholder data on a free Knack account first, then upgrade and execute your BAA when you are ready to go live.

Why Bolt needs an external HIPAA backend

Before getting into the steps, it helps to understand exactly where the compliance gap sits in a Bolt-built healthcare app. Bolt’s default backend is called Bolt Database, and it is a Supabase project that StackBlitz manages on your behalf. Supabase itself can be made HIPAA compliant under specific conditions, but the Bolt layer sitting above it is not covered by a BAA. Bolt sends your prompts to Anthropic-powered AI models, and Bolt’s Terms of Service does not cover what those models do with data. Consequently, the Bolt layer remains a gap even with a Supabase BAA in place.

Instead, the solution is to move PHI out of that gap entirely. When you connect Knack Health as the backend via the MCP server and runtime API, patient data never enters Bolt’s infrastructure at runtime. Knack Health becomes the data layer. Bolt remains the interface layer. For a deeper explanation of why Bolt is not HIPAA compliant and how the compliance boundary works, that post covers the full picture. For a broader look at secure vibe coding across all AI builder tools, that guide covers the same pattern for Lovable, Claude Code, Base44, and Bolt.

Before you start: what to prepare

Set up your Knack account

Start a free Knack account at knack.com if you do not have one already. For production healthcare apps that will handle PHI, you will need a Knack Health HIPAA plan with a signed BAA before going live. However, a free account works fine for setup and testing with placeholder data.

Build your data schema in Knack first

Specifically, the MCP server gives Bolt’s AI visibility into your existing Knack schema. Consequently, the integration works best when you define your tables, fields, and relationships in Knack’s visual Builder before connecting Bolt. For a patient intake app, that might mean a Patients table with fields for name, date of birth, and contact information. An Appointments table connected to it would be a typical companion structure. Building this structure first means Bolt’s AI generates accurate, schema-matched components from the first prompt. In other words, you avoid generic placeholders that need manual reconciliation.

If you are migrating an existing Bolt project to Knack Health as the backend, start by identifying which data your Bolt app currently stores. Then recreate that structure in Knack’s Builder. Notably, the Bolt frontend stays intact throughout.

Have your Knack Builder credentials ready

The MCP server authenticates via OAuth using your Knack Dashboard and Builder credentials. No API keys or developer tokens are required. Have your Knack email and password ready before starting the connection steps.

How to connect Bolt to a HIPAA-compliant backend

The following steps connect Knack Health as your bolt hipaa backend. Follow them in order for the fastest setup. All PHI will flow to Knack’s infrastructure at runtime, not to Bolt’s default backend.

Step 1: Open Bolt project settings

First, open the Settings panel in your Bolt project. Navigate to Integrations or MCP Servers. The exact menu path may vary depending on your Bolt version, but look for an integrations, connections, or backend configuration area.

Step 2: Add the Knack MCP server

Click Add Integration and select MCP Server as the type. Enter the following URL:

https://mcp.knack.com/mcp

This is Knack’s MCP server URL. It is the same URL used across all supported AI coding tools, including Lovable, Claude Code, Base44, and ChatGPT.

Step 3: Complete the OAuth authentication

After saving the MCP server URL, Bolt will prompt you to authenticate. Complete the OAuth flow using your Knack Builder credentials. On first use, Bolt opens a browser window for the OAuth consent screen. Sign in with your Knack email and password. Notably, no API keys or tokens are required.

Once authenticated, Bolt’s AI gains visibility into your Knack application’s schema. That includes your table names, field names, data types, and relationships.

Step 4: Confirm the connection

After authenticating, test the connection by asking Bolt a question about your Knack schema. For example, ask Bolt to list the tables in your Knack application. Alternatively, ask it to describe the fields in a specific table. If it returns accurate schema information, the MCP connection is working. At that point, you are ready to build.

Step 5: Build or update your frontend components

With the MCP server connected, Bolt’s AI understands your Knack data model. From this point, describe what you need to build. Bolt then generates frontend components, forms, and UI elements that map directly to your actual Knack fields and tables. The AI also generates accurate Knack API calls alongside the interface components.

For example, you might tell Bolt: “Build a patient intake form that collects name, date of birth, phone number, and reason for visit. Submit each record to the Patients table in Knack.” Bolt then generates the form. It also creates the corresponding Knack API calls using your real field names and table structure.

Step 6: Configure runtime API calls

At runtime, all record operations must go through Knack’s runtime API, not Bolt’s default backend. That includes creating, reading, updating, and deleting patient records. Confirm that the frontend components Bolt generated are calling Knack’s API endpoints rather than Bolt’s own storage. For new builds, this happens automatically when Bolt generates components against your Knack schema via MCP. For existing Bolt projects, you may need to update existing API calls to point to Knack instead of the Bolt Database.

Full technical documentation for the runtime API is at docs.knack.com/docs/mcp.

Step 7: Execute your BAA and upgrade to a HIPAA plan

Before any real patient data enters the system, confirm you are on a Knack Health HIPAA plan with a signed business associate agreement in place. The BAA covers all PHI stored in Knack Health’s infrastructure, including data flowing in from your Bolt frontend. Only after your BAA is executed should real patient data flow through the app.

For a checklist of every item to verify before going live, the HIPAA compliance checklist for no-code apps covers each requirement at the implementation level.

How the architecture works at runtime

Once your app is live, the MCP server is no longer in the picture. Instead, your Bolt frontend communicates with Knack Health via Knack’s runtime API for every record operation. Consequently, PHI flows directly from the user’s browser to Knack Health’s HIPAA-compliant infrastructure. Specifically, the data never touches Bolt’s backend.

Specifically, this architecture means the compliance boundary sits cleanly at the Knack layer. Bolt handles the interface layer and is not in the PHI data path at runtime. Consequently, the question of whether Bolt itself is HIPAA compliant becomes irrelevant for data storage purposes. The headless Knack guide covers how the build-time and runtime split works in detail, including why this architecture produces a production-ready compliance posture.

Migrating an existing Bolt project to Knack Health

If you already have a working Bolt frontend and want to switch the backend to Knack Health, the process follows the same steps above. Notably, you do not need to rebuild the Bolt frontend. The interface stays exactly as it is. The migration happens at the data layer.

For most Bolt projects, the migration involves three tasks. First, recreate your existing data structure. Second, connect the MCP server and update API calls. Third, migrate any existing records. First, recreate your existing data structure in Knack’s visual Builder (the same tables and fields your Bolt app currently uses). Second, connect Knack’s MCP server to your Bolt project and update your frontend’s API calls to point to Knack instead of the Bolt Database. Third, migrate any existing records from the Bolt Database to Knack before going live with the new backend.

The Knack Health team can assist with data migration for teams with existing records. Specifically, contact the team via knack.com/health/ before starting a migration with live patient data.

For a comparison of this architecture against building directly in Knack Health, the MCP server setup guide covers when the two-layer approach makes sense. It also covers when building entirely within Knack Health is the better fit.

What Knack Health provides as the HIPAA backend

For healthcare teams connecting Bolt to Knack Health, the HIPAA safeguards are included on every HIPAA plan.

Signed BAA

Every Knack Health HIPAA plan includes a signed Business Associate Agreement covering all PHI stored in Knack’s infrastructure. That includes data flowing in from Bolt frontends connected through the MCP server and runtime API.

Encryption at rest and in transit

Knack Health encrypts all PHI at rest using AES-256. Furthermore, all data in transit is encrypted using TLS, covering every transmission between the Bolt frontend, the runtime API, and Knack’s backend.

Role-based access controls

Knack Health enforces field-level permissions across every view, form, and API call. For example, a front desk coordinator sees scheduling fields. Clinical staff see clinical notes. Billing staff see financial data only.

Record change logs

Knack logs every access to and change of a patient record automatically, capturing who performed the action, when, and what values changed. This satisfies HIPAA’s record-keeping requirements without additional configuration.

HIPAA-ready infrastructure

Knack Health runs on AWS GovCloud hosting, the same infrastructure tier used by US government agencies with strict data security requirements.

For healthcare teams that prefer to build directly in Knack Health, the AI app builder provides a similar plain-language building experience. Specifically, it runs inside a fully HIPAA-compliant environment from the first prompt.

FAQ

Can I use Bolt to build a HIPAA-compliant healthcare app?

Yes, with the right backend architecture. Specifically, the bolt hipaa backend setup through Knack Health is what makes it possible. Bolt handles the frontend. Knack Health handles all PHI at the data layer via the bolt hipaa backend connection. At runtime, PHI flows directly to Knack Health’s infrastructure through Knack’s API and never touches Bolt’s backend. The Bolt interface stays exactly as it is.

Specifically, the URL is https://mcp.knack.com/mcp. In your Bolt project, open Settings, navigate to Integrations or MCP Servers, click Add Integration, select MCP Server as the type, and enter this URL. Complete the OAuth flow using your Knack Builder credentials. No API keys or tokens are required.

No. The Bolt frontend stays exactly as it is. Instead, the connection happens at the data layer. The connection happens at the data layer. After connecting the MCP server, update your frontend’s runtime API calls to route to Knack instead of Bolt’s default backend. The interface your users see does not change.

No. Specifically, Bolt’s default backend is a Supabase project managed by StackBlitz. Even if you claim that project and move it to your own Supabase account with a Supabase BAA, the Bolt layer itself is not covered. Specifically, how Bolt processes prompts through AI models falls outside the scope of that BAA. The compliant path is to move PHI out of Bolt’s infrastructure entirely by routing all data through Knack Health’s runtime API instead.

Before any real patient data enters the system. You can build and test with placeholder data on a free Knack account. Upgrade to a Knack Health HIPAA plan and execute your BAA before going live with any real PHI. The BAA must be in place before patient data enters Knack’s infrastructure.

The architecture is the same across all three tools. Each connects to Knack Health via the MCP server at build time and routes PHI through Knack’s runtime API at runtime. The Bolt-specific difference is the settings path: in Bolt, navigate to Settings, then Integrations or MCP Servers. In Lovable, navigate to Connectors in the left sidebar. In Base44, navigate to Account Settings, then MCP Connections.

Full technical documentation is at docs.knack.com/docs/mcp, including Bolt-specific configuration steps. For the broader MCP server setup guide covering all supported tools, that post covers the general steps and the healthcare-specific setup context. For an overview of what the MCP server launch enables across all supported tools, the launch post covers the background and use cases.