bonfire is a library, not a data processor. On the OSS tier it runs in your AWS — we never touch your PHI, so you operate under your own AWS BAA. Need us to host it? The managed tier comes with a BAA we sign, backed by our own AWS BAA. Either way, encryption, audit, ABAC, and consent are built in — not bolted on.
Most "HIPAA-compliant" backends ask you to ship your patients' data into their cloud and trust their controls. bonfire's default is the opposite: the open-source tier runs entirely inside your AWS account. The data layer is yours, the encryption keys are yours, the audit trail is yours. We're a dependency in your package.json — like Postgres or pgvector — not a third party holding your records.
The OSS tier deploys into your own account. Postgres, pgvector, the read models, the FHIR projection — all inside your VPC, under your IAM, in your region.
Encryption uses your KMS keys. The AuditEvent stream lands in your store. There's no console of ours where your PHI can be browsed, because it isn't there.
Encryption at rest and in transit, automatic audit + provenance, ABAC with minimum-necessary, and a live consent engine are part of the data layer — you don't assemble them.
This is the question every compliance buyer asks first, so here's the honest, unambiguous answer — it turns on who holds the PHI, not on marketing.
Choose the tier that matches who you want holding the PHI. If your security team would rather no vendor ever touch the data, run OSS in your own account and there is no BA relationship to negotiate.
// OSS tier — runs in YOUR AWS account const stack = await bonfire.deploy({ account: "your-aws-account", region: "us-east-1", kmsKey: "arn:aws:kms:…:key/your-cmk", }); // → we never see the PHI ⇒ not your BA // Managed tier — we host + sign a BAA // backed by our own AWS BAA // same SDK, same controls, you don't run infra
Encryption isn't a toggle you remember to flip. On the OSS tier, bonfire is designed to provision storage with KMS-backed encryption at rest and TLS everywhere on the wire — using keys that live in your account, so you control rotation, revocation, and who can decrypt.
clinical.encryption.config({ // at rest: your customer-managed KMS key (CMK) atRest: { kms: "arn:aws:kms:…:key/your-cmk", rotate: true }, // in transit: TLS to the DB and to every client inTransit: { tls: "required" }, // field-level envelope encryption for the most sensitive kinds fieldLevel: ["ssn", "psychotherapyNotes"], });
Honest framing: bonfireDB is pre-launch / early access. Encryption-at-rest, TLS in transit, and customer-managed KMS keys are part of the product design described here. Field-level envelope encryption for the most sensitive kinds is on the roadmap; the API shape above is how it's intended to be configured.
The biggest gap in most clinical stacks is the AuditEvent nobody wired up. In bonfire the audit record is part of the operation — every read, write, export, and agent call emits a FHIR AuditEvent with actor, patient, purpose, and outcome, automatically.
Because audit lives inside the access gate, the side doors that leak elsewhere — export, history, GraphQL — are logged here like any other read. See clinical authorization & audit for how the gate works.
{ resourceType: "AuditEvent", action: "R", // read outcome: "0", // success agent: { actor: "clinician:dr-okafor" }, entity: { patient: "pt-123", record: "Observation/o-9" }, purpose: "treatment", via: "agent:session-prep" // audited like any read }
HIPAA's minimum-necessary rule isn't a policy document in bonfire; it's a function the data layer runs on every request. Patient–clinician scoping, tenancy isolation, role-scoped kinds, and a live consent engine all gate reads and writes — there is no export door, history door, or agent door that skips them.
clinical.access.policy({ // tenancy: a request can only touch one tenant's data tenant: (ctx) => ctx.orgId, // patient scope: clinician must be assigned to the patient canReadPatient: (ctx, patientId) => clinical.assignments.exists({ clinician: ctx.userId, patientId }), // minimum necessary: scope which kinds a role may read minimumNecessary: { front_desk: ["appointments", "demographics"], clinician: ["notes", "assessments", "observations"], }, // consent as a live engine — withdrawn = closed on next request consent: (ctx, patientId) => clinical.consent.active({ patientId, purpose: "treatment" }), });
Every clause runs on both directions. A write that violates tenancy, minimum-necessary, or consent is refused the same way a read is — the policy doesn't care which verb you used. Consent is evaluated per request: withdraw it and the next read fails closed, including $export and history.
A clinical backend you can't leave isn't a backend — it's a hostage situation. Because FHIR R4 is generated from your source of truth, leaving is a function call, not a migration project. Ask for the Bundle and you get a clean, standards-shaped copy of everything.
The honest trade-off: running OSS in your own account means you own the operational burden — patching, backups, key rotation. The managed tier exists for teams who'd rather we carry that, under a signed BAA. More on FHIR underneath →
// leave anytime — no migration, no support ticket const bundle = await clinical.fhir.export(patientId); bundle.resourceType; // "Bundle" bundle.type; // "collection" // or the whole tenant, for migration or backup await clinical.fhir.exportTenant({ orgId, to: "s3://your-bucket" }); // flows through the same audited access gate
These are the controls a compliance buyer maps to the HIPAA Security Rule. In bonfire they're properties of the data layer, not a checklist you implement yourself.
The BA distinction in one line: on the OSS tier bonfire runs in your AWS and never handles your PHI, so it is not a Business Associate and there's nothing for us to sign — you operate under your own AWS BAA, like any library. On the managed tier we host it and therefore are your Business Associate, so we sign a BAA with you, backed by our own AWS BAA. Pick the tier that matches who you want holding the PHI.
bonfireDB is pre-launch / early access. We'd rather be precise than impressive: here's what's real, what's planned, and where the line is. Certifications are earned, not claimed.
We will not put a certification badge on this page until we hold it. SOC 2 and HITRUST are on the roadmap; if you need a current attestation today, the OSS tier lets you inherit your own controls and your own AWS BAA in the meantime.
The one gate every read, write, export, and agent call runs through.
Explore →Generated R4 Bundles power export, migration, and no-lock-in.
Explore →Postgres source of truth, fresh on commit, no Redis to put under a BAA.
Explore →The full clinical data layer — primitives, semantic search, MCP, and more.
Explore →Run it in your own AWS under your own BAA, or let us host it and sign one with you. Either way, encryption, audit, ABAC, and consent ship in the box.
bonfireDB is designed so the compliance controls a buyer maps to the HIPAA Security Rule are built into the data layer: encryption at rest with KMS, TLS in transit, automatic AuditEvent and Provenance, ABAC with minimum-necessary, and a live consent engine. It is pre-launch / early access, and on the OSS tier you inherit your own AWS BAA and controls rather than relying on a vendor certification.
It depends on which tier you run. On the OSS (Apache-2.0) tier, bonfire runs in your AWS and never receives your PHI, so it is not a Business Associate and there is nothing for us to sign; you operate under your existing AWS BAA. On the managed tier we host it and handle PHI, so we are your Business Associate and sign a BAA with you, backed by our own AWS BAA.
Yes. The OSS tier deploys entirely into your own AWS account, including Postgres, pgvector, the read models, and the FHIR projection, all inside your VPC, under your IAM, in the region you choose. Encryption uses your KMS keys and the audit stream lands in your store, so we never see your PHI.
HIPAA minimum-necessary is a function the data layer runs on every request, not a policy doc. Patient-clinician scoping, tenant isolation, role-scoped kinds, and a live consent engine gate both reads and writes, and there is no export, history, or agent door that skips them. Withdraw consent and the next request fails closed.
No. SOC 2 Type II and HITRUST CSF are on the roadmap but not yet certified, and we will not put a badge on the page until we hold it. If you need a current attestation today, the OSS tier lets you inherit your own controls and your own AWS BAA in the meantime.