I Built a HIPAA-Compliant CMS with Bolt and Xano

If your app touches health data, the rules are different. HIPAA is a federal law, and violations come with real consequences. Not bug reports. Regulators.

I built a full HIPAA-compliant content management system. Bolt for the frontend, Xano for the backend. Now, I want to walk through how it works.

I also made a video covering this if you'd rather watch:

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole thing took only a couple days. Made a video walking through the build and breaking down what HIPAA actually requires if you're a developer. Are you building a healthcare app? Let me know in the comments 👇

linkedin.com

What HIPAA actually requires from developers

HIPAA (Health Insurance Portability and Accountability Act) governs how Protected Health Information (PHI) is stored, transmitted, and accessed. PHI is any data that identifies a person and relates to their health: name, date of birth, diagnosis, insurance ID, even an IP address in certain contexts.

If your app stores any of this, you need encryption, access controls, audit logging, and legal contracts (BAA/BASA) with every vendor in the chain.

The stack

Frontend: Built in Bolt. One prompt describing the CMS I needed, pointed at my Xano API, working UI in minutes.

Backend: Xano, with HIPAA addon enabled. The workspace runs on an isolated, hardened server on Google Cloud (which is itself HIPAA certified). All traffic encrypted in transit over TLS.

Field-level encryption

Encryption isn't just a database-wide toggle. In this CMS, sensitive fields are individually encrypted using AES-256. A patient's diagnosis, their SSN.. each field is encrypted independently.

In the Xano function stack, the encryption logic looks like this:

Create Variable: aes_key = env:HIPAA_AES_KEY
Create Variable: aes_iv  = env:HIPAA_AES_IV
Create Variable: decrypted = AES decrypt(encrypted_value, aes_key, aes_iv)

Even if someone with database access can see the table, they can't read encrypted field values without the decryption key. The key lives in environment variables, never in the function stack itself.

Two layers of access control

This is the part I think matters most.

Layer 1: What we built. At the application level, we implemented our own role-based access control as middleware and our own audit logging.

Every API endpoint runs through a precondition check. If a non-admin user tries to hit a protected endpoint:

{
  "code": "ERROR_CODE_ACCESS_DENIED",
  "message": "Admin privileges required to access this resource."
}

That's not Xano blocking them. That's our code!

Layer 2: What Xano provides. Underneath everything we built, Xano has its own RBAC and audit logging built into the platform. Every workspace action is tracked. Who did what, when, what changed. Platform-level access controls govern who can even see the workspace.

Two independent layers. The platform enforces compliance at the infrastructure level. The app enforces it at the application level. That's what a HIPAA audit wants to see.

Audit logs

Same two-layer principle. Xano tracks every workspace action automatically. But we also built application-level audit logs: who published an article, who edited a patient record, who changed permissions. And you control who can access those logs — compliance officer gets read-only, lead dev gets full access, junior dev sees nothing.

The contracts: BAA and BASA

Any vendor touching PHI signs a Business Associate Agreement (BAA). But if a dev team was hired by a hospital and that team works with Xano, the right instrument is a BASA — Business Associate Subcontractor Agreement. Xano offers both.

Making changes safely

Healthcare apps need safe deployment workflows. In Xano, you can branch your workspace, make schema changes in isolation, test your API calls against the new structure, and confirm your frontend handles it before anything goes live. If something breaks, one click rolls back to the previous version.

Shared responsibility

One thing worth being direct about: HIPAA compliance is a shared responsibility. Xano provides the compliant infrastructure. But you're still responsible for your own policies, access controls, employee training, and incident response. The infrastructure doesn't make you compliant on its own. You have to use it correctly.

Try it

If you're building a healthcare product, Xano's HIPAA plan gives you the infrastructure and Bolt gets you a frontend fast.

I covered the full build in a video —

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole thing took only a couple days. Made a video walking through the build and breaking down what HIPAA actually requires if you're a developer. Are you building a healthcare app? Let me know in the comments 👇

linkedin.com

Want to see a webinar on how I did this? Drop a comment!