Dify for HIPAA: keeping PHI out of model providers

Dify for HIPAA: which Security Rule requirements the platform helps with

Self-hosting Dify helps with technical safeguards and evidence, but it does not make your deployment HIPAA compliant, and no certification exists that proves otherwise. HHS states that no Security Rule standard requires certification and that it does not endorse private certifications, so any vendor or partner claiming a HIPAA certificate for Dify is making a claim you should challenge. The Security Rule (45 CFR Part 164 Subpart C) applies to covered entities, which are health plans, health care clearinghouses and covered health care providers, and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. Whether your team is the covered entity or the business associate changes which obligations sit with you, so settle that role before you choose a model provider.

Within the technical safeguards in 45 CFR 164.312, a self-hosted Dify gives you places to apply controls: a SECRET_KEY that must be set and protected because it encrypts OAuth credentials, workspace encryption keys that can be stored locally or in Azure Key Vault, and SSRF_PROXY settings that block outbound requests to internal and private IP ranges. Dify 1.16.1 added agent sandbox network isolation and token-based authentication between services. Access control, unique user identification, automatic logoff, audit controls and log retention still depend on your identity provider, your logging stack and your procedures. The Security Rule also requires risk analysis, workforce training, contingency planning and documentation (the administrative and organizational standards), which Dify cannot perform for you. Treat the platform as one input to your risk analysis, and confirm each Dify setting against your own environment.

The Dify features that matter most here are not the ones your workflow designers see first. Confirm which model providers, embedding services and file storage backends will receive PHI, and whether each has a signed business associate agreement under 45 CFR 164.314 that flows the terms down to subcontractors. Confirm also what the Dify Enterprise tier provides for SSO and audit logging, since the Community edition is limited to a single workspace and lacks those controls, and check current Dify documentation for the controls you plan to rely on. HHS audits focus on hacking and ransomware risks, so the evidence your team keeps about these decisions matters as much as the configuration itself.

Mapping HIPAA Security Rule requirements to Dify capabilities and configuration

This table maps the HIPAA Security Rule technical safeguards and business associate contract terms to what a self-hosted Dify provides and what you must configure. Read each row as a split between platform capability and your own obligations, since several rows depend on a model provider contract or your written policy. The main takeaway is that self-hosting keeps PHI inside your environment, but a third-party model endpoint only fits the design once a signed agreement covers it.

Requirement	Dify capability	Configuration you set	Depends on
Unique user identification (164.312(a)(2)(i), required)	Named workspace accounts; Enterprise SSO with OpenID Connect, SAML or OAuth2	Ban shared logins; assign each user a named account; on Enterprise, configure SSO per workspace	Your account issuance policy and the records kept by your identity provider
Emergency access procedure (164.312(a)(2)(ii), required)	Self-hosted deployment in your infrastructure, so access depends on your own admin accounts	Document a break-glass admin account and test restoring the PostgreSQL database and file storage from backup	Your written procedure, who may invoke it and how emergency use is logged
Automatic logoff (164.312(a)(2)(iii), addressable)	SECRET_KEY signs session cookies and JWTs; changing it logs out all users	Confirm the session lifetime setting in the environment reference; plan any SECRET_KEY rotation as a forced logout	Whether a timeout is reasonable for your risk; if not, document an equivalent measure
Encryption of stored data and credentials (164.312(a)(2)(iv), addressable)	SECRET_KEY encrypts OAuth credentials; workspace encryption keys can be stored locally or in Azure Key Vault	Set SECRET_KEY before first start; choose key storage; enable encryption on database, Redis and object storage volumes	Disk and bucket encryption in your infrastructure; confirm which provider API keys SECRET_KEY covers
Encryption in transit (164.312(e)(2)(ii), addressable)	Nginx serves the front end; SSRF_PROXY routes outbound requests through a proxy that blocks internal and private IP ranges	Configure TLS on the Nginx entry point; set SSRF_PROXY; require TLS on every model and vector store endpoint	Certificate management and internal network paths; the provider's TLS terms in its contract
Business associate contract terms (164.314(a)(2)(i))	Self-hosted models keep PHI in your environment; each external provider or storage vendor is a separate party	Send PHI only to self-hosted models or to endpoints covered by a BAA; record every vendor in your inventory	Entirely dependent on provider contracts; confirm each vendor's BAA, subcontractor flow-down and incident reporting terms
Audit controls (164.312(b), standard)	LLMOps monitoring for app activity; Enterprise audit log with export options	Set log retention in your own stack; export Enterprise audit logs to your SIEM before the online query window closes	Retention length, log review cadence and who reviews activity are set by your policy

Where PHI can go: self-hosted models or a provider under a BAA

A self-hosted model endpoint keeps prompts, retrieved passages and completions inside the boundary you control. Dify calls the endpoint over the network you configure, so the question shifts from a vendor contract to how your own infrastructure is secured, logged and reviewed. The Security Rule still applies to every system that creates, receives, maintains or transmits electronic protected health information, so the inference server, its storage and its logs belong in your risk analysis.

Network path: Confirm the endpoint sits on a segment reachable only from the Dify api and worker services, and that Dify's SSRF proxy settings (SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL) do not route internal traffic to an unintended destination.
Model storage and caches: Inference servers often write model files, prompt caches or request logs to local disk. Identify those paths and include them in encryption and backup scope.
Model provider entry: In Dify, a self-hosted model is added under the model provider settings with its endpoint and credentials. Record who can add or change these entries, because they determine where prompts are sent.
Maintenance access: Vendor support or remote troubleshooting of the model server is a disclosure path. Write down who can reach it and under what agreement.

Before relying on this option, confirm with your infrastructure and security teams that the endpoint's own logs, debug output and telemetry settings have been reviewed for PHI.

What audit evidence a self-hosted Dify produces and how to keep it

HHS does not certify HIPAA compliance, so there is no certificate to hand over. What an OCR review or an independent assessor samples is the record of how the Dify deployment was built, changed, configured and governed. The cards below list the records you must assemble and keep, and what each one should show.

Deployment and version records

Record the Dify version running in each environment, the image tags, the Docker Compose version and the date each change went live. Keep the GitHub release notes and the upgrade guide for every version you deploy, so you can show which security changes were in effect on a given date. Confirm that production, staging and any test instance are tracked separately, since an auditor will ask which environment touched PHI.

Pre-upgrade backup records

The Dify Docker Compose docs recommend a backup before every upgrade. Keep dated records showing what was backed up, where it is stored, who ran it and whether a restore was tested. A backup with no record of its existence or its restore test is weak evidence when the Security Rule asks for data backup and recovery planning.

Environment configuration baseline

Keep a version-controlled baseline of the .env file with secret values removed, so each change is visible. Record who set SECRET_KEY, when it was generated and that it was stored in a secrets manager, because changing it after deployment logs out all users. Also record the log retention, outbound proxy (SSRF_PROXY) and storage settings that protect ePHI, and review the baseline after each upgrade, since .env.example may add new variables.

App DSL exports as configuration history

Export each production app as a YAML DSL file on a fixed schedule and after every approved change, and store the files in a repository with access controls. The exports hold workflow nodes, prompts and model parameters, which show what the app was doing on a given date. They do not contain third-party API keys, knowledge base content or usage logs, so those records must be kept separately.

SSO and role records

On Dify Enterprise, SSO connects workspace and web app access to your identity provider, so access reviews can draw on identity provider records rather than local accounts. Export the list of users, roles and workspace memberships at each review, and record who approved each access change. On Community, where SSO is not included, keep a manual access register that names every account with PHI access and the reason for it.

Model provider contracts and vendor records

For each model provider, keep the contract or business associate agreement, the region and data retention terms, and the record showing which Dify workflows call that provider. Under 45 CFR 164.314, a business associate contract must require subcontractors that handle ePHI to meet the same terms, so confirm each provider's position in writing. Self-hosted model endpoints need their own records, since no vendor contract covers them. Confirm the current terms with each provider, because they change.

Configuring a HIPAA-oriented Dify deployment in sequence

This sequence moves a Dify deployment from scoping where PHI may appear to a tested, documented environment in which PHI reaches only the model endpoints your organization has agreed to use. Each step produces a record that your compliance lead, security team and any auditor can review.

Scope where ePHI may appear
Your privacy or security officer, with the Dify builders, lists every app, knowledge base, file upload, log, trace and export that could hold electronic protected health information. Include embeddings, vector indexes and object storage, because they often hold derived patient data. Record which entities are covered entities or business associates for each flow. The step is complete when the risk analysis is documented and each data location has an owner and a named purpose. Confirm the analysis method with your compliance advisor, since the Security Rule requires a risk analysis but this page does not set its format.
Choose Community or Enterprise edition
Decide which edition fits the access model. The Community edition is free and limited to a single workspace. The Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security and professional support, according to the Dify pricing page. If you need per-user identity, separate workspaces for PHI and non-PHI work, or SSO scopes for web apps, the Enterprise quote becomes part of the scope. Ask the vendor to confirm the current feature list in writing. The step closes with a signed decision record that names the edition and the reasons.
Deploy inside your own accounts
Your platform team deploys Dify in cloud accounts, data centers or networks you control, using the Docker Compose or Kubernetes layout chosen in the earlier step. Confirm that the host meets the documented minimums of 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, then size it for real load. Place PostgreSQL, Redis, the vector store and object storage in the same controlled boundary. The step is complete when all services run in your environment, network paths are documented, and no PHI-bearing component depends on an endpoint outside the agreed boundary.
Set SECRET_KEY and encryption key storage
Your security engineers generate a strong SECRET_KEY and store it in your secrets manager, not in a shared file. The Dify environment reference says this key signs session cookies and JWTs and encrypts OAuth credentials, and that changing it after deployment logs out all users, so decide the value before production data arrives. Choose where workspace encryption keys live: locally or in Azure Key Vault. Record who can read these values and how rotation would be handled. The step is complete when a restore test shows the stored credentials remain usable and the key custody record is signed off.
Route outbound calls through SSRF_PROXY
Your network team configures the SSRF_PROXY settings so that outbound requests from Dify pass through a proxy, which the environment reference says blocks internal and private IP ranges. Restrict egress from the api, worker and sandbox containers to the approved model endpoints and document each allowed destination. Confirm the release that introduced agent sandbox network isolation through a Squid proxy, and test it. The step is complete when a blocked internal address and an approved provider endpoint both behave as the configuration intends, and the test results are kept with the change record.
Sign provider BAAs before PHI flows
Your legal and procurement teams confirm, for each model provider, embedding service, rerank model and observability tool, whether a business associate agreement is in place before any PHI is sent. Under 45 CFR 164.314, a business associate contract must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI and require incident reporting. Where a provider will not sign, route only non-PHI workloads to it, or host the model yourself. The step is complete when each provider has a signed agreement on file and the Dify model settings match the approved list.
Configure SSO and roles for unique user identification
Your identity team integrates Dify with your identity provider, using the protocols the Enterprise SSO documentation lists, such as OpenID Connect, SAML or OAuth2. Assign each person a unique account, disable shared logins, and map roles to the minimum access each team needs, separating workspace access from web app access. The Security Rule treats unique user identification as a required implementation specification, so test that every action traces to one person. The step is complete when an access review export matches the approved role model. On Community, document how individual accounts are managed and confirm that this meets your requirement.
Set log and file retention
Your operations and compliance teams decide how long conversation logs, uploaded files, traces and backups are kept, then set those values in Dify and in your storage and log platform. Confirm the default cleanup behavior in the Dify documentation before relying on it, and align retention with your documented policy and any legal hold obligations. Set access restrictions on exported DSL files, which exclude API keys but may still reveal prompts and knowledge base connections. The step is complete when retention settings, storage lifecycle rules and log sinks are documented and tested against a sample record.
Test backup and restore before go-live
Your platform team takes a full backup of the database, file storage and configuration, then restores it into a separate environment. The Dify Docker Compose guidance recommends a backup before every upgrade, and the same discipline applies before go-live. Verify that apps, knowledge bases, credentials and user access come back intact, and that restored data keeps the same retention and encryption controls. Record the recovery steps and the people who run them. The step is complete when a restore test passes, the runbook is approved, and the results are filed as evidence for your risk analysis.

What the platform does not cover for HIPAA

A self-hosted Dify can hold controls that support the Security Rule, but the covered entity or business associate still owns the program around it. The cards below cover the work that no software setting replaces, and the decisions that determine whether PHI stays out of model providers in practice.

Risk analysis and risk management

The Security Rule expects a documented risk analysis of every system that creates, receives, maintains or transmits ePHI, followed by risk management measures. A Dify deployment adds new places PHI can land: prompts, conversation logs, uploaded files, knowledge chunks and model provider requests. Your analysis should list each of these, the model endpoints they reach and the controls chosen for each. Refresh it when you add a model provider, workspace or plugin.

Workforce training and sanctions

Workforce security and sanctions policies are administrative safeguards that no product configuration can supply. Staff who build Dify workflows need to know which data may enter a prompt, which model endpoints are approved for PHI and how to report an accidental disclosure. Document a sanctions policy for misuse, such as pasting patient records into an unapproved tool. Keep training records as evidence for your own reviews.

Physical safeguards of the hosting facility

The physical safeguards in 45 CFR 164.310 apply to the facilities and devices where Dify runs, including the data center, cloud regions you select, backup media and workstations used for administration. Your cloud provider or colocation operator may hold part of this evidence. Ask for their documentation, confirm the hosting location meets your policy, and record which safeguards they operate and which you own.

Business associate agreements

Any model provider, hosting vendor or support partner that handles ePHI needs a business associate contract that meets 45 CFR 164.314(a). Dify itself does not replace that contract. Check whether each model provider signs a BAA and under what terms, and confirm that subcontractors handling ePHI are bound by the same obligations. Self-hosted models in your own environment still require a review of any vendor that touches the data.

Incident response and breach reporting

Incident response procedures, security incident reporting and breach notification sit with the covered entity or business associate. Dify logs and traces can help you determine what was exposed, but they only help if retention, access and export are planned in advance. Define who triages a suspected PHI disclosure into a model provider, how you preserve evidence and how you meet notification duties.

Pending Security Rule revision and no certification

HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), and no final rule has been published as of October 2026. Track the rulemaking through the Unified Agenda, since the final rule may change requirements. Separately, there is no HIPAA certification: HHS does not recognize private certifications, so any vendor or partner claim of HIPAA certification should be treated with caution. Dify Enterprise pricing is custom and must be quoted from a written scope, and the Community edition is limited to a single workspace, which may not fit a multi-team deployment.

Questions buyers ask before using Dify for PHI

Does self-hosting Dify make it HIPAA compliant?

No. Self-hosting keeps Dify data in infrastructure you control, but HIPAA compliance is a property of your whole environment, policies and contracts, not of a software install. The Security Rule in 45 CFR Part 164 Subpart C applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit. Dify is one component: the model providers, hosting, backups, logs, identity and staff procedures all fall inside that scope. There is also no HIPAA certification to show, since HHS states that no Security Rule standard requires certifying compliance. Ask your compliance lead to map each safeguard in 45 CFR 164.308, 164.310 and 164.312 to a named control in your deployment.

What must a business associate agreement contain, and who signs it?

A business associate contract under 45 CFR 164.314(a)(2)(i) must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. The contract is signed between the covered entity and each business associate that handles ePHI. In a Dify deployment, that can include your hosting provider, a model provider that receives PHI in prompts, an embedding or rerank vendor, and an outside implementation partner with access to systems. Confirm with each vendor whether it will sign a BAA and under what terms, and review the contract with counsel. Do not assume a vendor's standard terms cover your use case.

Is the Community edition enough for PHI workloads?

It depends on what you need beyond a single workspace. The self-hosted Community edition is free and limited to one workspace according to the Dify pricing page. The Enterprise edition adds SSO, multiple workspaces, advanced security, a commercial license and professional support, and its pricing is custom. Community edition can run in a controlled environment, but you would build identity, separation, log export and backup procedures yourself. Ask Dify for the Enterprise feature list and the license terms, and confirm in writing which controls your compliance team needs before choosing an edition. Note that the Dify license prohibits operating a multi-tenant environment without written authorization.

How are logs retained, and where does the audit trail come from?

Start by listing every place PHI can land: conversation logs, uploaded files, knowledge chunks, traces and database records. The Security Rule expects audit controls and documented retention decisions, so retention must be set on purpose, not left at defaults. Dify's own cleanup settings and log retention need to be checked against your policy and against the documentation requirements in 45 CFR 164.316. Dify Enterprise offers organization-wide audit logging, and you should confirm its retention window and export options with the vendor. Route exported records to a log store you control, test restores, and assign an owner who reviews access to the logs themselves.

Which model provider settings keep PHI inside your boundary?

Any model endpoint that receives a prompt containing PHI becomes a disclosure point, so the safest default is a self-hosted model reachable only from your network. If you use a cloud provider, confirm a signed BAA covers the specific service, region and retention settings you plan to use, and turn off any provider-side training or logging the contract does not allow. Dify can route requests through many providers, so restrict which models each workspace may call and log every provider used. Protect provider keys as secrets: Dify uses SECRET_KEY to encrypt OAuth credentials, and changing it after deployment logs out all users, so store it in your secrets manager and plan rotation carefully. Verify provider behavior with your own tests before handling real records.

What drives the effort and cost of a HIPAA-ready Dify deployment?

The main drivers are the number of PHI data flows, whether you use self-hosted or contracted models, how many environments and workspaces you run, and how much of the control evidence you must produce. Costs fall into software licensing (Community is free, Enterprise is custom priced), infrastructure, implementation, security testing, and recurring work such as upgrades and access reviews. Dify releases roughly monthly according to its GitHub releases page, so budget for a regular upgrade cycle with backups before each change. Ask any partner for a fixed-scope quote built from a written scope that lists data flows, environments, identity integration, model providers, backup targets and evidence deliverables. DeployOpen works through written scope before work starts and does not publish prices.

What must our team provide before the work starts?

You will need to provide the data flow inventory, your risk analysis and policies, the list of model providers and their BAA status, identity provider details, network and hosting constraints, and the target infrastructure with its backup and key management services. You should also name a compliance owner, a technical owner for Dify and an approver for PHI test data. Expect the platform to require at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later for the Docker Compose deployment, while production sizing will be higher. Ask for a written list of prerequisites in the scope before work begins.

Can our in-house team do this work without a partner?

Yes, if your team already runs regulated infrastructure and has the time to map the Security Rule safeguards, configure Dify and keep the evidence current. The hard parts are rarely the install itself. They are the BAA chain, the risk analysis, consistent log retention, access reviews and the upgrade discipline. Start by assessing whether each addressable implementation specification in 45 CFR 164.308 to 164.312 is reasonable for your environment and documenting the alternatives you choose, as 45 CFR 164.306(d) requires. A partner can plan, implement and document the deployment inside your infrastructure, while your compliance function keeps accountability. Compare both options against the same written scope.

Building an audit trail the Security Rule can be checked against

The audit control standard in 45 CFR 164.312(b) requires a covered entity or business associate to record and examine activity in systems that contain or use ePHI, and the documentation standards in 164.316 require you to keep written evidence that your safeguards exist and are followed. Neither standard names a log format or a retention period, so the audit trail for a Dify deployment is only as strong as the logs you keep, where you keep them and who can read them. Decide that before the first patient-related workflow goes live, not after an inquiry arrives.

Dify's audit logging is an Enterprise feature according to the Dify Enterprise documentation, so a Community deployment should not be assumed to record administrative operations at that level. Confirm with Dify which operations its audit log captures in your version, how long records remain queryable online, and whether export is in CSV or another format. Also confirm which events are recorded only in application logs, conversation logs or the Dify database, because those sources have different retention behavior and different access paths. Ask for the exact list in writing as part of the platform evaluation.

Retention and export are decisions your organization owns. Dify's default cleanup behavior for stored records is not a HIPAA retention period, so set a documented retention schedule for audit records, conversation logs and workflow traces, and export older records to storage or a SIEM that your security team controls. Protect the export path with the same access model as the source system, and test a restore or query of an exported record so the evidence can be produced when an auditor or OCR investigator asks. Document the schedule, the owner of each log source and the review cadence in the same records that cover your risk analysis.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted Dify inside your own cloud accounts, data centers or air-gapped networks, so that PHI-bearing workflows run where you control the model endpoints, credentials and logs. We start from a written scope that names which workflows may touch PHI and which model providers, if any, sit under a business associate agreement.

How we scope

We inventory the apps, knowledge bases, plugins and model providers that could receive PHI, and record where each one runs.
The written scope states which model endpoints are self-hosted, which are cloud providers under a signed business associate agreement, and which are excluded.
We confirm with your compliance and legal teams which Security Rule controls the work supports and which remain your responsibility.

How we build

We configure the secret key, workspace encryption keys, outbound proxy rules and sandbox settings, and test each one before handover.
We set up metadata, file storage, vector store and log retention to match the retention periods your policy requires, not the platform defaults.
We configure access for administrators and app builders, and document how user identity, unique IDs and session timeouts are enforced.

How we hand over

You receive configuration documentation, a data-flow diagram showing where PHI is stored and transmitted, and a list of open items.
We provide backup and restore runbooks and a test restore record so your team can verify recovery without us.
Verification evidence covers configuration exports, access lists and log samples, and we explain which items an independent auditor will want to sample.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which covers reviewing each minor release for changes to security settings.
We do not issue HIPAA certifications or attestations; we prepare systems and evidence so your covered entity or an independent assessor can review them.