Dify for universities and education

Why a university running Dify needs to plan for FERPA before the first assistant

A university that puts a Dify assistant in front of staff or students should decide its FERPA position before anyone uploads a syllabus. Staff and students want assistants that answer questions about course material, advising rules, financial aid steps and administrative forms. Once those assistants read gradebook exports, advising notes, enrollment records or support tickets, the content may be education records under 34 CFR Part 99, which applies to any institution that receives funds under a program administered by the US Secretary of Education. Dify is an open-source LLM application platform that a campus can run in its own cloud account or data center, and the Community edition is limited to a single workspace. That limit matters: separating a registrar's assistant from an advising assistant, or a research group from a student-facing tool, is a design question to answer early, not a setting to adjust later.

Self-hosting does not settle the compliance position by itself. The position depends on three choices the campus makes: where the Dify services and their PostgreSQL, Redis and vector stores run, which identity system decides who can reach each app, and which model endpoints receive prompts and retrieved passages. A contractor or hosting partner may receive education records only under the school official conditions in 34 CFR 99.31(a)(1)(i)(B), which include direct institutional control and redisclosure limits, so the operating model needs to match that language. Dify Enterprise adds SSO and multiple workspaces, but the Community edition does not, so confirm early which identity features and workspace separation your chosen edition provides. Verify these points against the regulation text and your counsel's reading rather than assuming a deployment pattern satisfies them.

Which education requirements shape the Dify build

This table maps the education rules that change how a self-hosted Dify is configured, with the source for each and what the build must do about it. Read each row as a requirement, the configuration it drives, and the evidence your compliance lead will ask to see. Confirm your institution's obligations with counsel, since these rules apply differently depending on funding and the population served.

Requirement	What it asks for	What it means for the Dify build
FERPA school official access (34 CFR 99.31(a)(1)(i)(B))	A contractor may receive education records only as a school official, under the institution's direct control, and with redisclosure limits.	Scope the Dify deployment and any hosting partner under a written agreement. Keep student records out of workspaces that outside parties can administer.
FERPA legitimate educational interest (34 CFR 99.31(a)(1)(ii))	Access controls must limit school officials to records in which they have a legitimate educational interest.	Map Dify workspace roles and web app access to academic roles. Do not give broad workspace membership to staff who only need an assistant.
FERPA access records (34 CFR 99.32)	Record each request for and disclosure of personally identifiable information, with the parties and their interests.	Decide which Dify and platform logs capture user, app and knowledge base access, and set retention to match the records they describe. Confirm what the logs contain before relying on them.
FERPA inspection timelines (34 CFR 99.10(b))	Respond to inspection requests within a reasonable period and not more than 45 days.	Keep conversation histories, app configurations and knowledge base sources findable by student identifier so staff can assemble records within the deadline.
FERPA funding consequences (34 CFR 99.67)	Non-compliance can lead to withheld payments, a cease and desist complaint or loss of program eligibility.	Treat the access model, logging and vendor agreements as funding-relevant controls, not optional features, and document them before rollout.
COPPA under-13 users (16 CFR 312.2, 312.8, 312.10)	Operators collecting data from children under 13 need a written security program, a designated coordinator, annual risk assessments and a retention policy with a deletion timeframe.	If any K-12 or youth-facing assistant accepts under-13 users, disable open sign-up and set deletion jobs for chat data. Confirm with counsel whether the institution or the vendor is the operator.
GLBA Safeguards Rule for Title IV institutions (16 CFR 314.4(c)(5), 314.4(j))	Written information security program, multi-factor authentication for anyone accessing any information system, and FTC notification within 30 days for events affecting at least 500 consumers.	Require MFA through campus SSO for every Dify administrator and staff account. Build an incident path that includes Dify logs, database and object storage, and the FTC notice timeline.
GLBA annual compliance audits (FSA Electronic Announcement GENERAL-23-09)	The Department of Education examines GLBA compliance in annual compliance audits of Title IV institutions.	Keep dated evidence of Dify configuration, access reviews and upgrade records, since auditors will ask how the platform meets the Safeguards Rule.

Which Dify settings matter for a campus deployment

Campus identity decides who reaches staff tools and student assistants, so it should be designed before the first workspace is created. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2 as supported protocols, with identity providers such as Microsoft Entra ID and Okta named as examples. It also separates SSO scopes for workspace access and web app access, which means staff who build apps and students who only use them can be governed differently.

Protocol match: Confirm which of OpenID Connect, SAML or OAuth2 your campus identity provider supports and which one the Enterprise edition will be configured against.
Workspace scope: Limit workspace access to faculty, instructional designers and IT staff who build or maintain apps.
Web app scope: Give students access to published assistants through a separate scope so that building rights do not follow from student login.
Community limits: The Community edition is limited to a single workspace, and the Enterprise SSO features are listed on the pricing page as Enterprise-only, so a campus that needs campus SSO across departments should plan for Enterprise from the start.
Sign-up policy: Decide who may create accounts directly, and close open registration for a campus-only deployment.

Confirm with your identity team how group or role claims map to Dify roles before pilot users are onboarded.

How a campus rollout moves from pilot to course-wide use

A campus rollout of self-hosted Dify moves through gated phases, so each widening of access follows a decision about data, identity and retention that the institution has signed off.

Scope data classes and user groups
The campus registrar, privacy office, IT security and the pilot faculty list the data each assistant may touch, such as course materials, advising notes, or student records, and which groups will use it, such as instructors, staff and enrolled students. The output is a written scope that marks which records fall under FERPA education records rules and which users are minors, since COPPA applies to children under 13 and may matter for some K-12 or youth programs. Do not move to hosting until this scope is signed, because every later choice depends on it.
Choose hosting and database layout
The campus infrastructure team selects where Dify runs (campus data center or a cloud account the institution controls) and the layout for the metadata database, file storage and vector store. Docker Compose suits a small pilot, while the Enterprise Kubernetes path is the route the docs describe for high availability. Confirm the minimum host requirements in the Dify self-hosting docs, plan the secret key and encryption keys before first login, and confirm which model endpoints will be used. The step closes when a pilot environment is reachable only on the campus network and the database and storage choices are recorded.
Wire campus single sign-on
The identity team connects the campus identity provider to Dify so staff and students sign in with their campus accounts rather than local passwords. Community edition login options differ from Enterprise SSO, which lists OpenID Connect, SAML and OAuth2 with providers such as Microsoft Entra ID and Okta. Confirm with the vendor which protocol and provider the campus uses, and decide separately who gets workspace access and who gets web app access. The step closes when a test account from each user group reaches only the workspaces and apps its scope allows.
Load one course knowledge base as a pilot
A small team loads the materials for one course into a single knowledge base and builds one assistant around it, with the instructor reviewing answers against the source documents. The work covers document selection, copyright and licensing checks on course readings, and confirming that the pilot uses only approved model providers. Record which files went in, how many questions the instructor tested, and where the assistant gave incorrect or unsupported answers. The step closes with a written instructor sign-off and a list of fixes before wider use.
Review access and retention with the registrar
The registrar and privacy office review the pilot's access logs, the list of school officials with access, and any vendor or contractor role that touches education records. FERPA requires reasonable access controls so that officials see only records tied to their legitimate educational interest, and it requires a record of disclosures. The team also decides how long conversation logs, uploaded files and knowledge base content are kept, and confirms how deletion works in the environment. The step closes with signed retention and access decisions that the campus can show an auditor or a regulator.
Widen access course by course
Once the review gates pass, the campus adds more courses and user groups one at a time, each with its own knowledge base and sign-off from the instructor and the data owner. The platform team checks that new workspaces or apps keep the access model from the pilot, and that changes to Dify versions follow the upgrade guide, with a backup taken before each upgrade. The step closes when each new course has a documented owner, scope and retention setting, and the campus holds a current list of who can reach each assistant.

What do universities ask before hiring a Dify partner?

What drives the cost of a Dify implementation for a university?

Cost follows the written scope, and the main drivers are the number of workspaces and apps, how many identity providers and course systems must connect, the vector store and object storage you choose, and how much content must be classified and loaded into knowledge bases. Ask for a quote that separates one-time work (architecture, SSO, data loading, testing, handover) from recurring work (upgrades, support, testing retainers). Your own staff time for identity owners, data classification and model contract reviews is a cost that should appear in your internal budget even though it is not billed by a partner.

How long does a Dify rollout take at a university?

Duration depends on scope rather than a fixed number, and the biggest variables are how many campus groups are onboarded, whether Enterprise SSO and multi-workspace management are required, and how quickly your identity, privacy and procurement reviews can be completed. A narrow pilot with one staff assistant and one course knowledge base is far shorter than a campus-wide program with student-facing assistants. Ask any partner to state the phases, the exit criteria for each phase and which of your decisions gate them.

What must the campus provide before the engagement starts?

Three inputs decide most of the early work:

Identity owners who can confirm the campus SSO protocol, the attributes released to applications and which groups map to staff, students and instructors.
A data classification of the material you plan to use, including whether any education records or personal information of children under 13 could appear in prompts, uploads or knowledge bases.
Model contracts and approved provider lists, including data processing terms, retention settings and whether self-hosted models are available for student-facing use.

Also name an accountable owner for AI use policy so scope decisions have a sign-off path.

Can our own staff run a self-hosted Dify deployment?

Yes, if your team has container operations, database and storage administration, and an on-call path. Dify's Docker Compose deployment starts several core services, including the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, so someone must own patching, backups and monitoring. Many campuses split the work: internal staff own operations and identity, while a partner handles architecture, hardening, integrations and handover. Confirm your staffing model before choosing scope, because it changes the handover deliverables you should request.

What does Dify Enterprise add over the Community edition?

According to the Dify pricing page, the self-hosted Community edition is free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. The Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID and Okta, and separate SSO scopes for workspace access and web app access. Enterprise on Kubernetes also requires a larger platform footprint, so ask vendors for the license cost and infrastructure cost as separate line items.

How are Dify upgrades handled on a university platform?

Plan upgrades as a recurring operation with a release calendar. Dify minor releases arrive roughly monthly, for example 1.16.0 on July 17, 2026 followed by 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026, according to the GitHub releases page. Each upgrade should follow the upgrade guide for the target version, start with a backup, and check .env.example for new variables afterward. Ask any partner how they test upgrades against your SSO, knowledge bases and integrations in a non-production environment before production changes.

Does a partner's work make the university FERPA or GLBA compliant?

No. Compliance is an institutional obligation that independent auditors and regulators assess, and a partner does not issue audit reports or certifications. A partner can prepare access controls, logging, retention settings and documentation that your compliance office uses as evidence. For FERPA, confirm whether any vendor will be a school official under your institution's direct control and whether access is limited to records with legitimate educational interest. For institutions covered by the GLBA Safeguards Rule, confirm multi-factor authentication for every information system access path, since the rule requires it for anyone accessing any information system.

How do we protect student data when using self-hosted models?

Self-hosting keeps Dify's application data, knowledge bases and logs inside infrastructure you control, but it does not decide what a model may see. Set a data classification rule for prompts and uploads, restrict which apps can read student records, and confirm that outbound model calls go only to approved endpoints. Dify's environment reference notes that SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges, and that SECRET_KEY must be protected because changing it after deployment logs out all users. Verify each setting in your own environment before relying on it.

Which compliance controls a campus should evidence

A campus running Dify touches several federal rules at once: FERPA for student records, COPPA for children under 13, and the GLBA Safeguards Rule through Title IV participation. The cards below name the controls those rules tend to ask about and where Dify settings produce the evidence. DeployOpen prepares systems, controls and evidence, but auditors, the Department of Education and the FTC make the determinations.

Limit access to legitimate educational interest

FERPA expects the institution to use reasonable methods, such as technological access controls, so school officials see only the education records they need. In Dify, this means mapping staff and student roles to workspaces and web app access before any course material or advising records enter a knowledge base. Check who can open each knowledge base and each app, and confirm that a contractor's access is limited to the work it performs. The access model must be written down before data is loaded.

Log access and disclosures

FERPA requires a record of each request for and disclosure of personally identifiable information from education records, kept as long as the records are kept. Dify keeps application logs and usage data, but the campus must confirm which events it captures, how long they are retained in its database and file storage, and whether they can be exported to the campus logging system. Test a sample request end to end and keep the result as evidence.

Set retention and deletion for under-13 data

Campuses that run programs for children under 13, such as summer camps or K-12 partnerships, fall under COPPA's rules on retention. Operators may keep children's personal information only as long as needed for its purpose and must maintain a written retention policy with a deletion timeframe. In Dify, conversation history, uploaded files and knowledge base documents each need a stated deletion rule, and the cleanup jobs must be tested rather than assumed.

Enforce MFA and a written security program

The GLBA Safeguards Rule, which Title IV institutions agree to follow, requires a written information security program and multi-factor authentication for anyone accessing an information system. For Dify, MFA is typically enforced at the campus identity provider in front of the console and web apps, so the campus must confirm that the chosen SSO path supports it. The written program should name Dify as an in-scope system, its owner and its review cycle.

Control outbound requests from the platform

Dify agents, tools and workflows can call external URLs, which creates a path for data to leave the campus or for requests to reach internal systems. Dify's SSRF proxy settings route outbound requests through a proxy that blocks internal and private IP ranges, and newer releases isolate agent sandboxes at the network level. Document which destinations are allowed, record the proxy configuration as a control, and review it after each upgrade.

How self-hosted models and retention keep student data inside campus control

Where a Dify deployment sends student data is decided by three things the campus controls: which model endpoints the workflows call, what is placed into knowledge bases and app inputs, and how long the resulting records are kept. Each prompt, retrieved passage and model response leaves the Dify host whenever the selected model is a cloud service. Running campus-approved or self-hosted models keeps that traffic on campus networks, but only if every model provider entry in Dify points to an approved endpoint. Confirm the list of endpoints with your security team, then review the model provider settings in each workspace so that no app quietly routes to an unapproved service. Outbound requests from the platform can also be limited through the SSRF_PROXY settings, which route requests through a proxy that blocks internal and private IP ranges, and this should be reviewed alongside the model list.

The data that enters Dify is the larger risk for education, because staff and students often paste or upload material without thinking about what it contains. Limit knowledge bases to course materials that carry no student records, such as syllabi, readings and policy documents, and keep advising files, disciplinary notes and accommodation letters out of them. Retention needs a written schedule that names each store: the metadata database, file storage, the vector store and application logs. DSL exports of apps are not a complete backup or a complete transfer record. According to the Dify docs, exports include app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but exclude third-party API keys, knowledge base content and usage logs. Those three items need separate handling: store API keys in your secrets process, back up knowledge base content and logs under your own retention rules, and confirm the export format with a test import before relying on it.

Where accessibility and vendor contracts apply

Four obligations sit outside the Dify build itself but decide whether a student-facing deployment can go live. Accessibility, contractor status, the license terms and vendor support each have to be settled with the people who own the risk, and several points below should go to counsel before the first student uses the system.

Accessibility of embedded student apps

Web apps built in Dify and embedded in a course page or portal are web content the institution provides, so the accessibility rules in 28 CFR Part 35 Subpart H can reach them if the institution is a public entity. Test chat windows, citation panels, file upload controls and error messages with a screen reader and keyboard only, and record the results. Confirm with counsel which accessibility standard the institution is held to and whether the rule applies to every app or only to those students must use.

Contractor status as a school official

A partner or vendor that handles student education records can be treated as a school official only if it performs a service the institution would otherwise use employees for, works under the institution's direct control, and follows the redisclosure limits. Write those conditions into the statement of work and the data processing terms, and limit Dify access to records that have a legitimate educational interest. Confirm with counsel whether the institution's annual notice and its use of school official exceptions cover AI assistants that read advising or grade data.

Dify license limits on multi-tenant use

The Dify Open Source License is a modified Apache License 2.0 that bars operating the source code as a multi-tenant environment without written authorization, where one tenant is one workspace. Community edition is limited to a single workspace, so a university that wants separate workspaces for departments, a library, or a satellite campus should plan for that before design begins. The license also forbids removing or changing the logo or copyright information in the console, so branding changes need a check against the terms.

Vendor support terms to confirm

Community edition has no vendor support, while the Enterprise edition is custom priced and includes professional support, SSO and multiple workspaces. Ask any partner or the Dify vendor for written response times, security notification commitments, patch timing, and data processing terms before signing. Confirm where student data will be processed and how the vendor handles it. Confirm with procurement and counsel before the contract is signed, because support scope and liability decide who answers when a student record is exposed.

What the campus team has to provide before work starts

The campus team should settle five inputs before DeployOpen scopes the work, because each one changes what gets built and what it costs. The first is identity provider ownership. Dify Community sign-in is a local account model, while SSO with named identity providers, including Microsoft Entra ID, Okta and OpenID Connect or SAML sources, is documented for Dify Enterprise. If the registrar or IT group already runs the campus directory, the work becomes a connector and group-mapping exercise with a named owner for the identity provider. If no one owns it, the scope grows to include identity design, and the edition choice moves with it. Confirm who can change the directory, who approves new SSO applications and how staff and student groups are populated.

The second input is data classification of course material and student records. Ask the registrar and the privacy office to label each source as public course content, internal material, or education records covered by FERPA (34 CFR Part 99). Records classified as education records shape the knowledge base design, the retention settings and whether an outside service provider can be treated as a school official under 34 CFR 99.31(a)(1)(i)(B). Material from children under 13 brings in the COPPA Rule as well. Each class that moves into a separate workspace or storage target adds configuration and testing hours, so a short written classification is the cheapest input you can provide.

The remaining three inputs are approved model providers, storage and backup targets, and named owners for access reviews. List which model endpoints the university has contracts for, and whether any on-premises inference is approved for student data, since each endpoint adds credential handling and testing. Confirm the object storage bucket, the database host and the backup location, along with restore-test ownership, because Dify upgrades advise a backup before every upgrade. Finally, name the people who will approve access reviews for staff and student assistants each term. Without those owners, role design and review evidence cannot be finished, and that work is usually billed as an extension of the original scope.

How DeployOpen scopes and supports a campus Dify implementation

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Dify inside the university's own cloud accounts, data centers or networks. Each campus engagement starts from a written scope that sets out which assistants, knowledge bases, identity connections and model endpoints are included.

How we scope

Inventory the assistants, course knowledge bases and staff workflows the campus wants, and record which student data each one touches.
Agree the identity design for campus SSO, including which accounts can reach workspaces and which can reach published web apps.
Confirm which model endpoints, campus-hosted or contracted, may receive prompts and documents, and document the approval boundary.

How we build

Deploy Dify in the university environment and configure the metadata database, file storage and vector store the campus has approved.
Connect model providers and outbound proxy rules so that only approved endpoints are reachable from the platform.
Test access separation between staff, students and external users, then check that knowledge base content matches the course access rules.

How we hand over

Document the architecture, secret handling, access model, backup and restore steps, and upgrade procedure in a form the campus team can run.
Provide a record of configuration decisions and test results that the campus privacy and security offices can review.
Walk the campus IT team through daily operation, user onboarding for assistants and the process for retiring a course knowledge base.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing alongside the initial build.
Plan each Dify version upgrade with a backup first, a check of new environment variables and a test pass on a non-production copy.
Review access rules and model usage with the campus team each term, so assistant scope follows changes in courses and staff roles.