Dify for manufacturing: why the plant and engineering side needs control of its data
Engineering and maintenance knowledge lives in equipment manuals, work instructions, drawings and years of ticket history, and much of it is intellectual property that should not leave your environment. A self-hosted Dify deployment fits because it runs the application layer, knowledge bases and model calls inside infrastructure you control, so documents and prompts stay within your network boundary. Dify is an LLM application platform for building workflows, retrieval pipelines (RAG) and agents, not a general document store, so the design work is deciding which content goes into which knowledge base and which model endpoints can receive it.
Several decisions change for the build. Plant and engineering teams usually need on-premises or private model endpoints for proprietary content, so the model provider list, embedding models and credential handling must be agreed before any document is uploaded. Knowledge base scope needs the same care: a maintenance assistant should not see design drawings it has no need for, and ticket histories may carry customer or supplier details that need filtering. Integrations with ticketing and maintenance systems also need a planned identity and permission model, since an agent that opens or updates work orders acts on live records. Confirm with your vendors which connectors and plugins your systems support, and note that the Community edition of Dify is limited to a single workspace, so separating plant, engineering and maintenance teams may require the Enterprise edition, whose pricing is custom and quoted from a written scope. Check the Dify pricing page for the current feature split.
Which manufacturing requirements shape a Dify build
This table compares the standards and regulations that most often touch a plant or engineering Dify deployment, with the source for each and what it means for the build. Read the applicability column first, because several rows only apply to plants in certain sectors, markets or supply chains. Dify is not certified against any of these frameworks, so the table describes what your own program must show, and what Dify configuration can support.
| Requirement and source | What it asks for | What it means for a Dify build |
|---|---|---|
| ISA/IEC 62443 zoning and asset owner programs (ANSI/ISA-62443-2-1-2024, ANSI/ISA-62443-3-2-2020) | Asset owners run a security program and assess risk when designing zones and conduits between industrial control systems and business networks | Place Dify on the business or engineering side, outside the control network. Document which plant data flows in, and confirm the zone and conduit design with your OT security lead before connecting any document source. |
| NIS2 manufacturing scope (Directive (EU) 2022/2555, Annex II) | Manufacturing entities in NACE Rev. 2 divisions 26 to 30 and medical device makers fall within critical sectors, subject to size and classification rules | Applies only to in-scope EU entities. Confirm your classification with counsel, then record Dify as a system in your asset and incident inventory. |
| NIS2 incident reporting timelines (Article 23(4)) | In-scope entities send an early warning within 24 hours, a notification within 72 hours and a final report within one month of a significant incident | Logs, audit trails and admin contact paths in Dify must be retrievable fast enough to meet these clocks. Test the reporting runbook with a tabletop exercise that includes the Dify app owners. |
| NIS2 penalties for important entities (Article 34(5)) | Fines of at least EUR 7 million or 1.4% of worldwide turnover, whichever the national rules apply | Applies only to in-scope entities. The exposure is a reason to fund governance of Dify access and model data, not a cost estimate for the build. |
| Cyber Resilience Act reporting duties (Regulation (EU) 2024/2847, Articles 14 and 71(2)) | Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents, with these duties applying from 11 September 2026 | Applies to manufacturers placing connected products on the EU market. An internal Dify deployment is not itself such a product, but if you embed Dify apps in a product you ship, the reporting duties apply to that product. |
| CRA fines (Article 64) | Maximum fines of EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of essential requirements and Articles 13 and 14 | Applies only to manufacturers of products in scope. Ask your product compliance lead which Dify components, if any, become part of a shipped product. |
| Machinery Regulation protection (Regulation (EU) 2023/1230, Annex III, 1.1.9) | From 14 January 2027, machinery must be protected so that connecting another or remote device cannot cause a hazardous situation | Applies to machinery placed on the EU market. Keep Dify away from safety functions and PLC write paths, and treat any connection between an AI assistant and machine controls as a design change needing a safety review. |
| NIST SP 800-82 Rev. 3 (September 2023) | Guidance for OT security covering SCADA, DCS, PLCs and building systems, with attention to performance, reliability and safety | Voluntary guidance for US plants. Use it to justify keeping Dify out of real-time control paths and to shape monitoring and maintenance windows for the Dify host. |
| CMMC levels for defense suppliers (32 CFR 170.14) | Level 1 uses 15 FAR 52.204-21 safeguards, Level 2 uses 110 NIST SP 800-171 Rev. 2 requirements for CUI, and Level 3 adds 24 NIST SP 800-172 requirements | Applies only to defense contractors handling the relevant information. Confirm the current phase status with your contracting officer, because Phase II requirements were suspended on 13 July 2026, and confirm which level applies before scoping any CUI in Dify. |
How manufacturing knowledge maps to Dify knowledge bases and apps
The core design decision is which plant and engineering records become retrievable knowledge and which stay out. Manuals, work instructions and engineering notes are the natural candidates for a Dify knowledge base, because they are relatively stable and answer the questions shift teams ask most often. Each source type becomes its own knowledge base or a clearly labeled set of documents, so a technician asking about a pump can be answered from the current manual revision rather than from a superseded PDF. Maintenance logs are different: they are useful for trend questions but change constantly and often contain personnel and equipment details. Decide per source whether it is indexed, summarized in a controlled document, or queried live through a tool. Confirm with your Dify version which file types and sizes its document handling accepts, and test the parsing of your scanned or table-heavy manuals before you commit to a corpus.
Sources that should stay out of retrieval include controlled drawings and design files that carry intellectual property, anything under an export restriction or customer confidentiality clause, and unreleased engineering changes that a plant floor user should not see. Dify knowledge bases are only as governed as the workspace and dataset permissions around them, so keep those sources in a separate deployment or workspace with its own access model, and treat the decision as a documented data classification rule. Keep the metadata database, file storage and vector store inside your infrastructure, since the environment reference lets you choose each of these. Confirm where embeddings are generated and which model endpoint receives the text, because that determines whether intellectual property leaves your network.
Workflows suit repeatable shift and maintenance questions: a workflow can retrieve the relevant work instruction, check the equipment identifier supplied by the user, and return the step list with its source reference. Agents suit open-ended troubleshooting, where the model chooses between knowledge retrieval and a tool call, such as looking up open work orders in your maintenance system. Limit agent tools to read operations at first, and require a human confirmation step before any action that changes a work order or a machine state. Test answers against the revision history of each manual, and record which document version each answer cited so that engineering can reproduce the response later.
Settings and integrations that matter on the plant side
A plant-side Dify deployment touches manuals, work orders and maintenance records, so the settings that decide where data lives, how secrets are protected and what the platform can reach matter more than the feature list. The cards below cover the layout, the keys and proxies that guard outbound traffic, the sandbox, model routing and app version control.
Deployment layout and data stores
Docker Compose suits a single-site pilot, while Dify Enterprise on Kubernetes is the documented route to high availability with SSO and multiple workspaces. Confirm the metadata database (PostgreSQL is the default, with MySQL and OceanBase also listed), the object store for uploaded manuals, and the vector store, since Weaviate is the default and Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch are listed options. Choose the vector store before loading the first drawing set, because changing it later means re-indexing.
SECRET_KEY and workspace encryption keys
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out every user. Set it once, store it in your secrets manager and record who holds the backup copy. Workspace encryption keys can be kept locally or in Azure Key Vault, so decide before go-live which key store your security team will audit and how a key rotation is rehearsed.
SSRF proxy for ticketing and CMMS calls
Work-order and maintenance integrations are outbound HTTP calls, and SSRF_PROXY settings route them through a proxy that blocks internal and private IP ranges. That protects the plant network from a misconfigured tool, but it also blocks a CMMS or ticketing host on a private address unless you allow it deliberately. List each maintenance endpoint in the change record and test it through the proxy before a tool goes into production.
Agent sandbox isolation
Dify 1.16.1 added agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. For plant use, agents that run code or parse equipment data should be reviewed against these controls, and the release notes should be read on every upgrade. Confirm with your vendor which sandbox egress rules apply to your version.
Model routing to on-premises inference
Engineering documents often carry intellectual property, so route workflow model calls to inference servers inside the plant or data center rather than to a public endpoint. Each model provider and embedding model is a separate configuration with its own credential, so keep an approved list and check that no workflow falls back to a cloud provider when a local server is down. Confirm which embedding and rerank models your knowledge bases use, because they also see the raw documents.
App DSL export for version control
Dify apps export as YAML DSL files that include app configuration, workflow nodes, model parameters, prompts and knowledge base connections. The exports exclude third-party API keys, knowledge base content and usage logs, so the repository holds the workflow logic while credentials and documents are restored from your secrets store and document pipeline. Store the DSL in Git with review, and document the steps that re-attach keys and knowledge bases after import.
Where models run for intellectual property
In this option, Dify, its vector store, the metadata database and the model endpoints all run in your plant or engineering data center. Drawings, specifications, work instructions and retrieved chunks never leave your network, because the model is also served locally. The trade-off is that you own model hosting, capacity planning, patching and the GPU or accelerator budget. Dify connects to a model endpoint through its model provider settings, so the endpoint URL and any API key become secrets that the platform stores and uses.
- Data crossing the boundary: Nothing leaves the site by design, but outbound traffic from the Dify containers still needs review, including plugin downloads and update checks.
- Credentials to handle: Model endpoint keys, the Dify
SECRET_KEYand the database and object storage credentials. ChangingSECRET_KEYafter deployment logs out all users, so plan it before go-live. - Outbound filtering: Confirm that
SSRF_PROXYsettings block requests to internal and private ranges so a workflow cannot reach other plant systems by accident. - Model choice: Confirm with your engineering leads that the local model handles your technical language and tables well enough for the use case.
- Vendor and security confirmation: Ask the model or inference server vendor for its license terms, update cadence and whether any telemetry is sent home.
Before approving this option, confirm the exact network egress rules for every container with your security team and document them as part of the build record.
Here the model runs in a managed endpoint that you contract for, typically inside a private network path to a cloud region you select. Dify stays on your infrastructure, but prompts and retrieved context are sent to the endpoint for inference. Responsibility for model availability and hardware moves to the provider, while your contract, data processing terms and network path become the main controls. Confirm exactly which chunks leave the site, since retrieval results are often larger than the user's question.
- Data crossing the boundary: Prompts, retrieved knowledge base passages and tool outputs sent to the model in each request, which may include proprietary design details.
- Credentials to handle: The endpoint API key or cloud identity, stored as a Dify model provider secret, plus rotation ownership and who may read it.
- Retention and training: Ask the provider in writing whether inputs and outputs are logged, for how long, and whether they are used for training.
- Network path: Confirm whether traffic uses a private connection or the public internet, and whether the endpoint can be restricted to your address ranges.
- Contract and location: Confirm the processing region, subprocessors and audit rights in the agreement before any engineering content is sent.
Ask your legal and security teams to sign off on the exact data categories allowed through this path, not only the contract template.
In the mixed setup, a classification step decides which requests may use an external model. Only prompts built from general, non-sensitive content, such as generic writing help or public standard lookups, reach the external endpoint. Anything touching drawings, process parameters, formulas or customer specifications stays on an on-premises model. This gives access to stronger hosted models at a cost of more complex routing and a higher risk of misclassification. The routing rules and classification logic must be designed and tested, not assumed.
- Data crossing the boundary: Only the content that passes the classification rule, so the rule itself becomes a critical control.
- Credentials to handle: Two sets of model keys, with separate scopes so the external key cannot be used to call the internal endpoint or the reverse.
- Routing design: Decide whether routing is set per app, per workspace or per workflow node, and who can change it.
- Misclassification testing: Test with sample engineering documents that the rule blocks sensitive content, and record the results.
- Vendor and security confirmation: Confirm with both model vendors what they log and where, and ask your security team to review the classification method.
Do not treat this option as ready until the routing rules have been tested against documents your engineers consider sensitive.
How a manufacturing Dify rollout runs in phases
The sequence moves Dify from a contained pilot on one line's documents to a wider rollout, with each phase closing on a written check so that security, data handling and integrations are proven before access expands. Durations depend on scope and are set in the written plan.
Zone the network and classify data
Your infrastructure team and DeployOpen define where the Dify host, its database, vector store and object storage sit relative to plant networks, engineering file shares and any operational technology zone. Engineering owners classify manuals, drawings and work instructions by sensitivity so that each source has an agreed home. The step closes with a zone diagram and a data classification list signed by the data owners, with a clear rule that no control network connects to Dify.
Build a pilot knowledge base from one line
Start with the documents of a single production line, such as its work instructions and equipment manuals, rather than the whole plant archive. The team sets up the Dify knowledge base, tests chunking and retrieval against questions that maintenance and quality staff actually ask, and records where answers are wrong or cite the wrong revision. The step closes when the pilot group has reviewed a fixed question set and the failures are logged and assigned.
Review model endpoints and security settings
Decide which model endpoints may receive plant or intellectual property content, and whether those models run on infrastructure you control. Review secrets handling, the SSRF proxy configuration, sign-up policy, API exposure and the code sandbox settings against your security baseline. The step closes with an approved endpoint list and a documented configuration review, with any gaps recorded as accepted risks or fixes with owners.
Connect ticketing and maintenance in read-only mode
Connect the ticketing or maintenance system first through read-only access, so Dify can look up open work orders, asset records and past fault histories without writing back. Confirm with the system owner which fields are exposed, how credentials are scoped and how the connection is logged. The step closes when a sample of lookups matches the source records and the system owner approves the access scope in writing.
Establish the upgrade and backup routine
Before the pilot grows, set the routine for minor releases, which the Dify project publishes roughly monthly. Each upgrade follows the guide for the target version, begins with a backup, and checks new environment variables in the example configuration file. Restore a backup into a separate environment to confirm it works. The step closes with a written runbook and one completed test restore, owned by a named operator.
Widen access and add lines in controlled waves
Add further production lines and users in waves, each with its own document set, reviewed question set and access list. Track usage, retrieval failures and access requests, and review them with quality and maintenance leads before the next wave. The step closes when each wave has a sign-off from the line's owner and the operations team, and the accepted scope is updated in the written plan.
Compliance evidence a manufacturing team can prepare
DeployOpen can help a manufacturing team prepare the documents, system records and control evidence that regulators and assessors ask for around a self-hosted Dify deployment. Auditors, certification bodies and regulators reach the conclusions, so each card below describes what to assemble and what to confirm before a review starts.
Asset and zone documentation
Record every Dify component that touches plant or engineering data, including the api, worker, web, plugin daemon, PostgreSQL, Redis, the vector store and the code sandbox, and place each in a named zone. Map those zones to the control areas of the ISA/IEC 62443 series, which covers requirements for industrial automation and control systems. Confirm which systems an AI assistant can reach, because a knowledge base that indexes controller documentation or maintenance histories becomes part of the control environment for review purposes.
Incident reporting readiness
Under NIS2, manufacturing is a listed critical sector, and in-scope entities must report significant incidents on fixed clocks. Prepare a runbook that names who decides an AI-related event is significant, where the Dify logs and backups are kept, and who submits the early warning, notification and final report. Confirm that your Dify logs and workflow run records can be preserved and exported without relying on the platform team alone.
Vulnerability handling readiness
Where a manufacturer places a product with digital elements on the EU market, the Cyber Resilience Act obligations to report actively exploited vulnerabilities and severe incidents already apply under Article 14. For a self-hosted Dify, track each release on the GitHub releases page, record which versions run in production, and document how a security fix is evaluated, tested and deployed. Confirm whether your Dify use makes your organization a manufacturer of a product in scope, since that depends on how the platform is used.
Machinery safety interface review
The Machinery Regulation adds an essential requirement that machinery stay safe when another device or remote device connects to it. If a Dify agent sends commands, setpoints or maintenance actions to equipment, or reads from a control network, review that interface with your machinery safety team before deployment. Document which actions are read-only, which require a human approval step, and which are never automated. Confirm the application date with your compliance counsel and your notified body, if one applies.
CMMC scoping for defense suppliers
Defense suppliers that handle federal contract information or controlled unclassified information need to decide whether a Dify deployment falls inside their CMMC assessment boundary. Identify which knowledge bases, model endpoints and logs could hold that information, and state the boundary in writing. The Department of War suspended CMMC Phase II requirements in a July 2026 release, so confirm the current contract clauses with your contracting officer before changing the boundary. Scope decisions should follow the 32 CFR Part 170 levels, not the timing of a single release.
Access and change records
Assessors across these frameworks ask who could change a workflow, a prompt, or a knowledge base, and who approved the change. Plan Dify workspace roles, a named owner for each published app, and a change log that links app exports in DSL form to the ticket that approved them. Keep backups taken before each upgrade with their restore test results. Confirm whether your identity provider supplies the sign-in records you need, since Dify Enterprise SSO is a separate license.
What manufacturers ask before hiring a Dify partner
What drives the cost and effort of a Dify build for manufacturing?
Scope is the main driver: the number of manuals and work instructions to ingest, how many sources sit behind each knowledge base, the number of integrations with ticketing and maintenance systems, and how many models must run on your own hardware. Each of these adds discovery, configuration and testing time. Infrastructure is a separate cost line. The Docker Compose deployment needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, while the Dify Enterprise resources checklist calls for Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Ask any partner for a fixed-scope quote that lists deliverables, environments and integrations in writing before work starts. Most engagements are fixed-scope, so the written scope should state what is excluded.
Can our engineering team run Dify after the build is handed over?
Yes, if you assign owners for the platform, the knowledge bases and the integrations before the build starts. Running Dify involves container and database operations, backups, secret handling, upgrades and content governance for documents such as work instructions. Many plants already have staff who run Docker, PostgreSQL and object storage, so the gap is usually Dify-specific knowledge. Ask the partner to document runbooks, the environment variables that matter, and the backup and restore procedure, and to run a restore test with your staff present. Ongoing support, upgrades and continuous testing are available as retainers, so you can decide which tasks stay in-house and which you buy.
What do plant and IT staff need to provide for a Dify project?
Plant and engineering staff provide the source material and the subject knowledge: which manuals, work instructions and maintenance records are current, which revisions are superseded, and which documents carry intellectual property restrictions. IT provides the hosting environment, network paths to ticketing and maintenance systems, identity integration, storage and backup targets, and a change window for installs and upgrades. Expect to name a document owner in engineering and an approver in IT for each integration. Clear ownership at the start reduces rework when a document set turns out to be out of date.
How do Dify's monthly minor releases affect plant operations?
Dify minor releases arrive roughly monthly. The releases page lists 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Each upgrade needs a test cycle, because a change in a workflow node, plugin or vector store client can alter retrieval results for a knowledge base that engineers rely on. The Docker Compose docs advise a backup before every upgrade and checking .env.example for new variables. Agree on a release policy with your partner, such as which versions are approved, who tests them against reference questions, and how long a rollback window stays open. Also plan upgrades around production schedules so a release does not land during a shutdown or a critical maintenance period.
Is the Dify Community edition enough for a manufacturing site?
It can be enough for a single site with one workspace and a small group of users. The self-hosted Community edition is free and limited to a single workspace. Manufacturers with several plants, separate engineering and maintenance teams, or a need for single sign-on across groups usually need more. Check the Dify license before you deploy, because the Dify Open Source License forbids operating a multi-tenant environment without written authorization and forbids removing the logo or copyright information in the console. Ask your partner to map each team and plant to a workspace model before you commit to an edition.
What does Dify Enterprise add for a manufacturer?
The self-hosted Enterprise edition adds SSO, multiple workspaces, advanced security, a commercial license and professional support, according to the Dify pricing page. The Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID and Okta, and separate scopes for workspace access and web app access. Enterprise can also be deployed on Kubernetes for high availability. Confirm with Dify which features apply to your contract, since the edition is custom priced and quoted from your requirements.
How is pricing set for a Dify implementation from a written scope?
DeployOpen does not publish a price list. A quote follows from the written scope, which lists the knowledge sources, models, integrations, environments, hardening controls and handover tasks. Dify's own pricing has separate components: the Community edition is free, while the self-hosted Enterprise edition is custom priced. Your infrastructure costs are separate from both. When you request a quote, ask for one-time work and recurring costs to be shown separately, including support retainers, upgrade work and any model or hosting charges you will pay directly. Ask what is excluded, how changes to scope are priced, and which acceptance tests close the project.
What to ask a partner before the build starts
Start by asking which OT boundaries the partner will respect. A Dify deployment for manufacturing should sit in the business or engineering network, not on a control network, and it should never write to PLCs, SCADA or historians. Ask the partner to show the network zones and conduits in the design, who signs off on any path between Dify and the plant side, and how that design maps to the zone model in ISA/IEC 62443. Ask also how the outbound SSRF_PROXY settings will be set so that connectors to ticketing or maintenance systems reach only the named hosts. Ask for the design decision in writing before the build starts, because changing it later is expensive.
Next, ask how models and keys are handled. Confirm whether the partner will set up on-premises inference for drawings and intellectual property, and who holds the provider keys, the SECRET_KEY and any workspace encryption key. The Dify environment reference says changing SECRET_KEY after deployment logs out all users, so ask who controls rotation and when it is scheduled. Ask what the fixed scope covers: named connectors, the knowledge base sources, the test cases, the handover documents and the acceptance criteria. Ask who owns knowledge base updates after handover. A common answer is that the plant document owner approves each new manual revision and the engineering team runs the re-index, so confirm that split and the people behind it.
Finally, ask how retainers for support and upgrades work. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so ask what each retainer covers, how it responds to the monthly Dify minor releases, and whether an upgrade is tested against your manuals, workflows and connectors before it reaches production. Ask who pays for a new model or connector, and what is one-time against recurring. Request a quote that separates the fixed build from the retainer and states the assumptions about your environment. Confirm the release notes process with your change board early.
How DeployOpen scopes and delivers a manufacturing Dify implementation
DeployOpen plans, builds, documents and supports self-hosted Dify inside your own infrastructure, with the plant and engineering use cases defined before any build starts. Engagements are fixed-scope, so the knowledge sources, models, integrations and access rules are agreed in writing first.
How we scope
- Inventory the manuals, work instructions and maintenance records that each knowledge base would hold, and who owns them
- Classify engineering data by sensitivity so you decide which models may see it and where they run
- Define the ticketing, CMMS and identity integrations, with the access model and data flows written down before build
How we build
- Deploy Dify with Docker Compose or Kubernetes in your data center or cloud accounts, with secrets, SSRF filtering and sandboxing configured
- Connect approved model endpoints, including on-premises inference servers, and document each credential and its owner
- Build knowledge bases, workflows and tool integrations, then test retrieval quality and access rules against the agreed scope
How we hand over
- Deliver architecture, configuration, data flow and network documentation written for your engineers and security reviewers
- Run a handover session covering app export and import, backup and restore, and the upgrade procedure for each Dify release
- Record test results and open items so your team can repeat checks after each change
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build
- Plan minor release reviews, since Dify ships roughly monthly, and test each upgrade against your integrations before rollout
- Confirm with you which evidence your compliance and security teams need, and prepare it for independent assessors to review
