Deploying Dify for SaaS and technology teams
A SaaS or platform team that wants LLM features inside its product or internal tools should choose Dify when it needs visual workflow building, RAG and agents delivered through APIs in infrastructure it controls, but the license and tenancy model decides the architecture. The Dify Open Source License forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. A team that gives each customer its own workspace inside a shared Dify instance is therefore in license territory before any engineering starts. Ask counsel and the Dify team to confirm which model fits, and treat the answer as a gate on the design rather than a line item for later.
Compared with a generic deployment, three things change. First, customer data boundaries are drawn by workspace, app, knowledge base and API key, so the plan must state which tenant owns each vector index, file store and log, and how a request is traced back to one customer. Second, release cadence matters: the Dify 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, so minor releases arrive roughly monthly, and each upgrade should follow the target version's upgrade guide with a backup first. Third, audit evidence has to be assembled deliberately. A SOC 2 examination tests controls over a period, so the team should decide early which change records, access reviews, backup restore tests and log exports it will produce, and confirm with its auditor how those artifacts will be sampled.
Requirements SaaS teams bring to a Dify build
This table sets out the requirements a SaaS or technology company should check before building on self-hosted Dify, with the source fact behind each one and what it means for the build. Read each row as a decision point: the licence terms, the SOC 2 evidence model, the tenancy design, outbound request controls and the upgrade rhythm all shape the architecture before any workflow is built.
| Requirement | What the source says | What it means for the build |
|---|---|---|
| Multi-tenant licensing | The Dify Open Source License forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. | Serving many customers as separate workspaces in one Community install likely needs written authorization from the licensor. Confirm the licence position in writing before the architecture is fixed. |
| Workspace limits by edition | The Community edition is free and limited to a single workspace. The Enterprise edition adds multiple workspaces, SSO and a commercial license. | Per-customer workspaces point toward the Enterprise edition or a separate instance per customer. Ask for the commercial terms in writing as part of the quote. |
| SOC 2 common criteria | Every SOC 2 examination applies the security common criteria CC1 to CC9 from the AICPA 2017 Trust Services Criteria. | Map Dify access control, change management, logging and vendor risk to CC1 to CC9. Dify prepares the controls and evidence; an independent CPA firm issues the report. |
| SOC 2 categories | The five categories are security, availability, processing integrity, confidentiality and privacy. Security is always in scope. | Decide which categories the product's commitments cover. Availability and confidentiality usually drive the backup, encryption and tenant isolation design. |
| SOC 2 report type | A Type 1 report covers control design at a date. A Type 2 report adds an opinion on operating effectiveness over a period. | Start collecting operating evidence (access reviews, change tickets, backup restore tests) early, because a Type 2 examination needs a period of consistent operation. |
| Customer data separation | Each workspace holds its own apps, knowledge bases and encryption keys. Workspace encryption keys can be stored locally or in Azure Key Vault. | Define whether tenants share one database and vector store or get separate ones. Test that a retrieval query from one workspace cannot reach another workspace's knowledge base. |
| Secret signing key | SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials. Changing it after deployment logs out all users. | Generate and store the key before go-live and record it in your secrets system. Plan any rotation as a scheduled event with user notice. |
| Outbound request control | SSRF_PROXY routes outbound requests through a proxy that blocks internal and private IP ranges. Dify 1.16.1 added agent sandbox network isolation through a Squid proxy. | Confirm which tools and model endpoints need egress and allow only those destinations. Test that tenant-built tools cannot reach internal services or cloud metadata addresses. |
| Release cadence | Minor releases arrive roughly monthly, for example 1.16.0 on July 17, 2026 and 1.17.0 on August 25, 2026. Each upgrade should follow the target version's guide and start with a backup. | Set a patch window and a staging test cycle that match a monthly release rhythm. Track security notes in each release, since they can change the sandbox and authentication behavior. |
Choosing a tenancy model under the Dify license
The Community edition is free to self-host and is limited to a single workspace. Under the Dify Open Source License, a modified Apache License 2.0, the source code may not be used to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. A SaaS product that places several customers into separate workspaces on one Community install therefore falls outside the free terms. The license also forbids removing or modifying the logo or copyright information in the Dify console, which affects any white-labeled customer experience.
- Fit: Internal tooling for one company, or a single product workspace used by your own staff.
- Cost: No license fee for the software, but your team carries installation, upgrades, backups and support.
- Branding: Keep the logo and copyright information visible in the console.
- Upgrades: Minor releases arrive roughly monthly, so plan a recurring upgrade window.
- Boundary: Confirm in writing with Dify whether any internal use that serves external users counts as multi-tenant operation.
Before going live, confirm with Dify in writing that your intended use of a single workspace matches the license.
The self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support, according to the Dify pricing page. Because the commercial license is what replaces the open-source restriction for multi-workspace operation, this is the path to consider when one installation must hold several customer or business-unit workspaces. The Enterprise deployment is documented for Kubernetes with high availability, and its resources checklist lists Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, Qdrant and S3-compatible storage.
- Pricing: The pricing page does not publish an Enterprise figure, so the quote follows from your written scope, user count and deployment size.
- Recurring cost: Expect a license and support relationship that renews, alongside your own infrastructure.
- Workspace isolation: Ask how workspace boundaries, data separation and administrator roles are enforced across tenants.
- Commercial terms: Confirm whether the license covers your hosting of customer-facing workspaces and any resale or embedding terms.
- Infrastructure: Budget for the production resource profile in the Enterprise checklist, which is a vendor example rather than a requirement for your load.
Ask Dify to confirm the license scope for your exact customer model before signing a contract.
A separate Dify instance for each customer keeps each deployment to one tenant at a time, so the multi-tenant restriction is avoided at the architecture level. Each instance still has to be licensed under the terms that apply to its use. The Community edition is limited to a single workspace, so a per-customer instance on Community suits one workspace per install and is a question for Dify on the terms of commercial use. The model multiplies operating work, because each instance needs its own upgrades, secrets, backups, monitoring and access reviews.
- Operating load: Every instance adds upgrade, backup and patch work, which grows with customer count.
- Isolation: Separate databases, object storage and vector stores give strong data separation but raise infrastructure cost.
- Licensing per instance: Confirm whether the Community terms or an Enterprise agreement applies to each deployed instance.
- Provisioning: Automate instance creation and configuration so onboarding does not depend on manual steps.
- Support: Clarify who handles incidents when a customer instance fails, and in what hours.
Confirm with Dify whether the per-instance model is licensed as you plan to use it, and get that answer in writing.
Settings that matter for SaaS delivery
A SaaS product or internal platform team running Dify inherits a handful of settings that decide who can read what, how outbound calls are filtered and how apps move between environments. The cards below cover the settings to decide before the first tenant or customer workspace goes live.
Service API and app delivery
Customer-facing features usually call Dify through its backend-as-a-service APIs rather than the console. Decide which apps are exposed through service API keys, who issues those keys, and how end-user identity is passed through your own product. Keep keys scoped per app and per environment, and confirm how your product rotates a key without breaking live integrations. Confirm the current API authentication options with the Dify docs for your release before you design the key lifecycle.
SECRET_KEY and workspace encryption keys
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Generate it once, store it in your secrets manager, and treat rotation as a planned maintenance event. Also decide whether workspace encryption keys stay local or move to Azure Key Vault, and document who holds recovery material for each. Losing these keys can make stored credentials unreadable, so back them up with the database.
SSRF_PROXY outbound filtering
Workflows, tools and knowledge pipelines can make outbound HTTP calls on behalf of tenants, which is a common route to reaching internal services. The SSRF_PROXY settings route those requests through a proxy that blocks internal and private IP ranges. Confirm that the proxy is active in your deployment, test that a workflow cannot reach your internal metadata or admin endpoints, and list any internal systems you must allow explicitly so the exception is reviewed.
Agent sandbox network isolation
Release 1.16.1 added agent sandbox network isolation through a Squid proxy, along with token-based authentication between services and sandboxed Jinja2 template rendering. For a multi-tenant product, this limits what code an agent run can reach from the sandbox. Confirm that your deployed version includes these changes, test sandbox egress from a tenant-level test app, and track the release notes for each monthly minor release.
Vector store choice
The vector store defaults to Weaviate, with options such as Qdrant and pgvector. For SaaS delivery, the choice affects how tenant data is isolated, how backups and restores run, and who operates the cluster. Compare the operational footprint of each option against your existing database skills, confirm how each store separates per-workspace collections, and test restore time on a realistic data volume before committing to one store for all customers.
DSL export for promoting apps
Apps can be exported and imported as YAML DSL files, which covers app configuration, workflow nodes, model parameters, prompts and knowledge base connections. Exports exclude third-party API keys, knowledge base content and usage logs. Use DSL files to promote reviewed apps from a staging workspace to production, then re-enter credentials and re-link knowledge bases in the target. Record each promotion so a change can be traced back to a reviewed version.
Separating customer data per workspace without breaking the license
The license sets the design boundary before any architecture work starts. The Dify Open Source License forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. The Community edition is limited to a single workspace, so a SaaS team that gives each customer its own workspace needs written permission from the licensor or the Enterprise edition, which adds multiple workspaces. Confirm the exact terms with the licensor and the pricing page before you choose a tenancy model. Also plan for the console logo and copyright notices, which the license says must not be removed or modified.
Where workspace separation is allowed, treat it as the primary boundary and make the rest of the data path follow it. Give each customer's knowledge bases their own storage, vector index namespace and object storage prefix, and make sure file storage settings in the environment reference point to paths your team can scope and audit. Keep customer secrets and model credentials inside each workspace's own configuration rather than in shared environment variables. Where workspace encryption keys are used, decide per tenant whether keys are held locally or in Azure Key Vault, since that choice determines who can revoke access to a customer's data.
DSL exports are not a complete backup or a data transfer. The Dify docs say exports include app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but not third-party API keys, knowledge base content or usage logs. Plan those three categories as separate workstreams with their own owners, retention periods and deletion steps. Backups of the metadata database, file storage and vector store must carry the same tenant separation, and log pipelines must not mix customer identifiers across tenants. A restore test should show that one customer's data can be recovered and deleted without touching another's.
Rollout from pilot to production for a SaaS product
This sequence takes a Dify deployment from a written license position to a production service that delivers apps through APIs, produces SOC 2 evidence and absorbs monthly minor releases without losing control of the platform. Each phase ends with a named output that the next phase depends on.
Confirm the tenancy and license position in writing
Before any build, the company and its counsel confirm in writing how Dify will be used. The Dify Open Source License forbids operating a multi-tenant environment, where one tenant is one workspace, without written authorization, so a product that gives each customer a workspace needs that authorization or an Enterprise agreement. Community edition is limited to a single workspace, so the design also depends on how many workspaces the product needs. The output is a signed position note that names the workspace model, the edition and the logo and copyright obligations in the console.
Build a pilot sized to the minimum hardware facts
The engineering team deploys a pilot with Docker Compose, which needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, and starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. These figures are minimums, so the team sizes the pilot against its own load tests. Teams that expect high availability or Kubernetes operations should check the Enterprise resources checklist early, since it lists Kubernetes 1.24 or later, Helm 3.14 or later and a Qdrant cluster for production sizing. The output is a pilot that runs on the chosen layout with measured resource use recorded.
Design API delivery and key management
The platform and product teams decide how customer-facing features call Dify apps, which keys belong to which service, and how end-user identity reaches the app. Service API keys should be scoped per integration and rotated through a documented procedure, and SECRET_KEY must be generated and stored in a secrets manager because changing it after deployment logs out all users. The team also checks which outbound provider credentials sit in Dify and where workspace encryption keys are held, whether locally or in Azure Key Vault. The output is a key inventory, a rotation runbook and a documented API contract for each app.
Test the agent and API surface before launch
An independent security team tests the public API, the web apps, the agent tool calls and the sandboxed code paths before any customer traffic arrives. Testers should confirm that the SSRF proxy blocks internal and private address ranges, that the agent sandbox isolates network access as described in the 1.16.1 release notes, and that one workspace cannot read another workspace's knowledge bases or logs. Findings are logged against the release that was tested. The output is a test report with each finding closed, accepted or scheduled, and a retest record for anything fixed.
Collect SOC 2 evidence from the start
The compliance lead maps the Dify deployment to the security common criteria, CC1 to CC9, from the AICPA 2017 Trust Services Criteria, and decides which other categories are in scope. The team then collects evidence continuously rather than at audit time: access reviews for the console, change records for each upgrade, backup restore tests, key rotation logs and vulnerability test results. Dify does not issue SOC 2 reports, so the company engages an independent CPA firm for the examination. A Type 1 report covers control design at a date, and a Type 2 report covers operating effectiveness over a period. The output is an evidence index that the auditor can sample against.
Set a release process for monthly minor releases
Dify minor releases have arrived roughly monthly, with 1.16.0 on July 17, 2026 and 1.17.0 on August 25, 2026, so the release process is a standing workflow rather than an occasional project. Each release goes through a staging copy of the production stack, a recorded backup, the upgrade guide for the target version and a check of .env.example for new variables. Security-relevant release notes trigger the retest path from the earlier testing phase. The output is a dated change record for each upgrade, a rollback procedure that has been rehearsed and a named owner who approves production changes.
Operate, monitor and prove the controls over time
Once in production, the operations team tracks queues, worker health, storage growth and backup success, and feeds those records into the SOC 2 evidence index. Access reviews and key rotations run on the schedule set in the control design, and any exception is recorded with an owner and a decision. Retainers for support, upgrades and continuous testing can cover parts of this work, and the company should ask for their scope in writing. The output is a monthly operating report that shows the controls running as designed, which becomes the basis for the next audit period.
SOC 2 evidence a self-hosted Dify can support
A SOC 2 examination tests whether your controls work, and Dify is one system inside that scope. The cards below separate the platform settings and records you can point to as evidence from the decisions your own organization still has to document and an independent auditor still has to test.
CC1 to CC9 common criteria
Every SOC 2 examination applies the security common criteria CC1 to CC9, covering governance, communication, risk, monitoring, access, operations, change management and risk mitigation. For Dify, the platform touches CC6 (access and secrets), CC7 (monitoring and incidents) and CC8 (change management through upgrades). Map each criterion to a named owner, a Dify setting or runbook, and a dated record. Ask your auditor which criteria they will test against your system description before you build the evidence set.
Type 1 versus Type 2 reports
A Type 1 report describes your system and whether controls are suitably designed as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively across a period. For a Dify deployment, Type 1 needs the design documents, role model and configuration baseline. Type 2 needs proof that the controls ran every time over the period, such as access reviews, upgrade tickets and backup restore tests. Plan the observation window before the first upgrade or access change.
Restricted use of SOC 2 reports
SOC 2 Type 1 and Type 2 reports are generally restricted to specified users, such as your customers and their auditors, unlike general-use SOC 3 reports. When you sell a SaaS product that runs on Dify, decide which customer-facing summary you will publish and which detail stays under NDA. Confirm with your auditor whether a SOC 3 report fits your go-to-market needs. Keep the distribution list of who received the full report under your own records.
Trust Services categories in scope
Security is required in every SOC 2 examination, while availability, processing integrity, confidentiality and privacy are optional categories you select. Choose only the categories your product actually claims. For a Dify-based product, availability depends on the high availability design you run, confidentiality depends on workspace isolation and encryption key handling, and privacy depends on how end-user data is retained. Claiming a category without a matching control invites exceptions in the report.
Who prepares and who attests
DeployOpen plans, configures, documents and prepares evidence for a Dify deployment in your environment, including control descriptions and evidence folders. DeployOpen does not issue SOC 2 reports, attestations or certifications. An independent CPA firm performs the examination and issues the report. Agree the evidence list and the ownership of each control with your auditor and with DeployOpen in writing before the work starts.
EU processor terms and switching rules
For EU customers, GDPR Article 28(3) requires a processor contract that limits processing to documented instructions, including transfers, and requires security measures under Article 32. The EU Data Act requires data processing services to let customers switch to another provider or to on-premises infrastructure, and from 12 January 2027 switching charges are prohibited. Check that your customer contracts, export formats and Dify DSL exports support a credible exit. Note that DSL exports exclude third-party API keys and knowledge base content.
What SaaS teams ask before hiring a partner for Dify
What drives the cost of a Dify implementation and is a fixed-scope quote available?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The cost follows from that written scope, and DeployOpen does not publish a price list. The main drivers are the number of tenants or workspaces to design, the model providers and vector store to connect, the identity integration, the backup and upgrade process you want documented, and how much security testing or compliance evidence is included. Ask for a quote that lists each deliverable separately, states what is one-time and what recurs (such as a support retainer), and names what the client must provide.
How long does a Dify implementation take and what sets the duration?
The duration is set in the written scope, so ask for a timeline tied to named deliverables rather than a generic estimate. The main factors are how many workspaces and environments you need, whether you run Docker Compose or Kubernetes, how many external systems and identity providers are connected, and how much of your SaaS product's data flow must be documented for SOC 2 evidence. Client-side readiness also matters, including access to cloud accounts, approved model endpoints and decisions on data separation. Confirm with the partner which milestones depend on your team's approvals.
What does our team need to provide before the work starts?
Your team needs to provide the infrastructure and access the deployment will run on, plus the decisions that only your organization can make. In practice that means:
- Cloud or data center accounts, networks and sizing targets for the Dify host or cluster
- Approved model provider accounts and the credential handling rules that apply to them
- An identity provider and the user groups that map to Dify workspaces
- Your data classification for the customer data each workspace will hold
- Named owners for approvals, change windows and backup restore tests
Agree these inputs in the written scope so that delays can be attributed clearly.
Can our internal platform team run Dify without an outside partner?
Often yes, if the team has Docker, PostgreSQL, Redis and object storage experience and can own upgrades. The Community edition runs anywhere Docker runs and needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, according to the Dify self-hosting docs. The harder work is ongoing: Dify ships minor releases roughly monthly, each upgrade needs a backup and a check of .env.example for new variables, and tenant isolation requires care. Ask whether your team can staff that cadence. A partner is most useful for the design, the initial build and the hardening, while a retainer can cover recurring upgrades and testing.
How does the Dify Enterprise license change the decision?
The license choice decides whether you can serve multiple tenants on one installation at all. The Dify Open Source License forbids operating a multi-tenant environment, where one tenant is one workspace, without written authorization. The Community edition is free and limited to a single workspace, according to the Dify pricing page. The Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Before choosing, confirm the exact tenancy model with Dify in writing, and ask counsel to review the license terms against your SaaS offering.
What happens at each Dify monthly minor release, and who handles it?
Each minor release is a planned upgrade, not a simple image pull. Dify 1.16.0 was released on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026, according to the GitHub releases page. For each release, your operator should read the upgrade guide for the target version, take a backup, check .env.example for new variables, and test workflows and API calls in a staging environment. Security changes such as the sandbox network isolation in 1.16.1 should be reviewed on arrival. Ask any partner whether upgrades are included in the scope or covered by a retainer, and who signs off on each change.
What does DeployOpen do after go-live, and what is included?
Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope build. A retainer is the usual way to cover monthly upgrade planning, backup verification, security testing cycles and changes to model or identity connections. Confirm in the written scope which items recur, their response expectations and how changes are approved. DeployOpen does not issue SOC 2 reports or certifications; an independent auditor does, so the scope should describe the evidence DeployOpen prepares for that auditor.
How DeployOpen scopes and supports a SaaS Dify build
DeployOpen plans, implements, hardens, documents and supports self-hosted Dify inside your own cloud accounts or data centers, for SaaS and technology teams. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Written scope names whether Dify serves internal tooling, a customer-facing API or both
- Scope records how many workspaces exist and whether tenants need separate deployments
- Scope lists the license review needed before any multi-tenant operation of Dify
How we build
- Deployment, tenant isolation, secrets handling and outbound request controls are configured and tested together
- Customer data separation per workspace is verified with test accounts before go-live
- Evidence for SOC 2 controls is collected as the system is built, not reconstructed later
How we hand over
- Runbooks cover backups, restores, upgrades and the environment variables that change between releases
- Architecture, tenant model and control mapping are documented for your auditor and engineers
- Your team receives access, configuration exports and a walkthrough of each operating procedure
How we support
- Retainers cover upgrades as Dify minor releases arrive, with a backup taken before each upgrade
- Continuous security testing of APIs and the agent layer can be added to the retainer
- Support scope, response expectations and upgrade frequency are confirmed in the written agreement
