What a Dify implementation involves
A self-hosted Dify rollout puts the platform's three main working areas on infrastructure you control: visual workflows, retrieval-augmented generation (RAG) knowledge bases, and agents that call tools and models. Teams usually scope the work after one of three triggers: a pilot that has outgrown a cloud trial, data residency rules that stop prompts and documents from leaving your environment, or a need to route requests to internal model endpoints instead of public providers. Each trigger changes the list of components you must deploy, back up and secure, so the first deliverable should be a written inventory of apps, data sources, model providers and the users who will sign in.
Edition shapes the scope. The self-hosted Community edition is free and limited to a single workspace, according to the Dify pricing page. If you need several isolated workspaces, SSO or a Kubernetes high availability layout, those requirements point to the custom-priced Enterprise edition. Confirm this against your requirements before any architecture work, because it decides whether the project is a single Docker Compose stack or a larger platform build with a different team and budget.
Teams with strong container and database skills often build the platform in-house. The Compose stack is documented and the components are familiar: PostgreSQL, Redis, a vector store, object storage, a reverse proxy and a code sandbox. Partners add the most value in three places: scoping decisions that are expensive to reverse (metadata database, vector store, object storage and model routing), secrets and sandbox design such as the SECRET_KEY handling and the SSRF proxy configuration, and fixed-scope delivery with written acceptance criteria. Ask any partner to show how they will handle each of those three in the statement of work.
Before you request a quote, decide who owns the model credentials, who approves new apps and who restores the database if an upgrade fails. Those answers determine how much of the work is platform engineering and how much is governance. A quote should list the environments, the components deployed, the number of apps and knowledge bases to build, the identity integration, the backup and restore test, and the handover documentation, so that you can compare it with an in-house estimate line by line.
What the work includes and what you receive
A fixed-scope Dify rollout covers the environment, its data services, model access, first applications and the handover documents. The cards below list each work item and the deliverables you keep afterward.
Environment build on Compose or Kubernetes
We build the runtime in your cloud account, data center or air-gapped network, using Docker Compose for a single-host Community deployment or Kubernetes for a clustered layout. The Compose stack needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. Confirm the target platform early, because it changes the host count, the load balancer and the upgrade process.
Metadata database, vector store and object storage
We configure PostgreSQL as the metadata database unless you require MySQL or OceanBase, select a vector store (Weaviate is the default, with Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch as options) and connect file storage such as S3-compatible or Azure Blob. Each choice affects backup scope and sizing, so record it in the configuration records before build starts.
Model provider setup and credential storage
We connect the model providers your policy approves and store each API key in your secret store, not in .env files or the console. Ask who owns provider accounts, who rotates keys and which model endpoints are allowed for each workspace. Provider usage and billing stay with your accounts and are outside the implementation fee.
SECRET_KEY and secret handling
We generate SECRET_KEY, set it before first user login and document where it is held and backed up. The variable signs session cookies and JWTs and encrypts OAuth credentials, so changing it after deployment logs out all users. We also set workspace encryption key storage and confirm that no secret appears in exported configuration.
First apps and knowledge bases
We build the first agreed applications and knowledge bases from your sample content, including prompts, workflow nodes and retrieval settings. Document content is not included in app exports, so ingestion is repeated in each new environment. Confirm the number of apps and document sets in the written scope.
Acceptance testing and handover
We run the acceptance tests you approve, covering login, model calls, retrieval results, backup restore into a test environment and the upgrade steps. Handover delivers the deployed environments, configuration records, app exports as YAML DSL files, a runbook and an upgrade procedure. Ask for the acceptance criteria in writing before work starts.
SSO, hardening and customization
Single sign-on, hardening and customization are separate work and are not included in the base environment build. Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, and hardening covers the code sandbox, SSRF proxy and network isolation. Each can be added to the written scope as its own deliverable with its own acceptance tests.
What drives cost and duration
Each row names a driver of implementation effort or recurring cost, explains why it moves the work, and gives the step that keeps it under control.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Deployment topology: Compose or Kubernetes | Compose needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. Enterprise on Kubernetes needs Kubernetes 1.24 or later and Helm 3.14 or later, plus more platform work. | Match topology to availability needs first. Confirm node counts and cluster prerequisites with Dify before the quote is written. |
| Community or Enterprise edition | Community is free and limited to one workspace. Enterprise is custom priced and adds SSO, multiple workspaces and professional support, which add configuration and licensing work. | List the multi-workspace, SSO and support requirements before scoping. Request an Enterprise quote only for needs that require it. |
| Apps, workflows and connected tools | Each app, workflow and external system adds build, testing and access work. Exports carry app configuration but not third-party API keys. | Agree a first-release list of apps. Connect tools in priority order and budget credential setup per tool. |
| Knowledge base volume and document types | Document count, formats and quality drive ingestion time, storage, chunking choices and retrieval tuning. Knowledge base content is not carried over in exports. | Inventory source documents, remove duplicates and stale files, and load knowledge bases in named batches with owners. |
| Model providers and routing | Each provider needs credentials, parameter testing and outbound access through the SSRF proxy, which blocks internal and private IP ranges. | Limit the first rollout to approved providers. Agree who owns credential rotation and where keys are stored. |
| Data stores: database, vector store and object storage | The Compose stack bundles PostgreSQL, Redis and Weaviate. Enterprise expects PostgreSQL 14 or later, Redis 6 or later, Qdrant and S3-compatible storage, each of which must be run, sized and backed up. | Decide on the database, vector store and object storage before build starts. Confirm which services are managed by your team. |
| Identity integration | Enterprise SSO supports OpenID Connect, SAML and OAuth2. Workspace access and web app access use separate SSO scopes, so each needs its own configuration and testing. | Confirm the identity provider, protocol and group mapping early. Decide which users need workspace access and which need only web app access. |
| Environments and upgrades | Each environment repeats deployment, secrets and configuration. Upgrades follow per-version guides, need a backup first and may add new .env variables. Minor releases arrive roughly monthly. | Keep the environment count small. Plan a recurring upgrade window and a test environment that mirrors production. |
| Compliance evidence, concurrency and sandboxed agents | Assessors expect access records, backup restore tests and change logs. Peak concurrent users and agents that run code in the sandbox increase sizing and isolation testing. The Enterprise production example uses six worker nodes, each with 8 CPUs and 32 GB of RAM. | Map required evidence to controls before build. Confirm peak concurrent users and agent use cases, and treat the Enterprise example as a reference, not a sizing for your workload. |
Project phases and outputs
The sequence moves from agreed scope to a configured, tested and handed-over Dify platform that your team can operate.
Run discovery and agree written scope
DeployOpen reviews your use cases, user groups, model providers, data sources, identity needs and hosting constraints with your architecture, security and business owners. The output is a written scope with deliverables, exclusions, acceptance criteria and a timeline that reflects the drivers in the scope. Work starts only after you sign off.
Make architecture decisions
The team records decisions on topology (Docker Compose or Kubernetes), metadata database (PostgreSQL, MySQL or OceanBase), vector store, object storage for files, and how secrets such as SECRET_KEY and encryption keys are stored. Each decision carries its trade-off and owner. The output is a signed architecture decision record that the build follows.
Build the hosting environment
DeployOpen provisions the compute, networking, TLS termination, storage, backup targets and outbound proxy paths in your cloud account, data center or air-gapped network. The core services are deployed and checked for health, and the sandbox and SSRF proxy are confirmed to run. The output is a working environment that matches the architecture record.
Configure the platform and model providers
DeployOpen sets environment variables, connects the chosen vector store and object storage, and configures model providers with credentials held in your secret store. Workspace roles, the first members and any agreed identity integration are set up. The output is a configured platform where each provider and store has been tested with a live request.
Build first apps and knowledge bases
DeployOpen builds the agreed first apps, workflows and knowledge bases with your subject-matter owners, including document ingestion, chunking and retrieval settings. Prompts and model parameters are versioned, and app configuration is exported as YAML DSL files for the record. The output is the agreed set of apps, each signed off against its written acceptance criteria.
Test and accept the platform
DeployOpen runs functional tests on apps and knowledge base retrieval, checks access controls, secret handling, sandbox and proxy behavior, and backup and restore on a copy. Findings are logged and fixed until the agreed criteria pass. The output is a test report and a signed acceptance record.
Hand over runbook and training
DeployOpen delivers a runbook covering operations, backups, upgrade steps per release, monitoring, incident response and secret rotation, then trains your operators and app builders on the platform. Access is transferred and support options are confirmed separately. The output is a documented, operable system and a training record for your team.
What teams keep in-house and what they outsource
This table compares, for each work item in a self-hosted Dify rollout, what teams usually keep in-house, what they usually outsource and the skills each side needs, so the split can be planned before a quote is requested.
| Work item | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Infrastructure provisioning | Account ownership, network zones, DNS, certificates and approval of the final environment | Building the hosts or cloud resources, Compose or Kubernetes manifests and environment files | Cloud or data center administration, Docker Compose, Linux, networking |
| Container or cluster operation | On-call ownership, patch windows, capacity decisions and upgrade approvals | Initial cluster or Compose setup, startup checks and the first upgrade rehearsal | Docker or Kubernetes operations, Helm for Enterprise deployments, monitoring |
| PostgreSQL and object storage operation | Backup retention rules, restore testing schedule, storage ownership and data classification | Database and bucket setup, metadata database configuration and file storage wiring | PostgreSQL administration, S3-compatible storage, backup and restore tooling |
| Model provider accounts and API keys | Contract signature, spend limits, key rotation owner and approval of approved providers | Entering keys into Dify provider settings and documenting where each credential is stored | Vendor console administration, secrets handling, understanding of provider billing |
| Workflow and prompt design | Business rules, acceptance criteria, sign-off on prompts and ownership of each app after launch | First app builds, prompt iteration with the team and workflow node configuration | Prompt engineering, Dify workflow editor, testing of LLM outputs |
| Knowledge base content preparation | Choice of source documents, access classification and decisions on what must not be indexed | Chunking settings, ingestion pipelines and retrieval tuning on sample content | Document governance, retrieval evaluation, vector store configuration |
| Integrations with internal systems | Owner approval for each system account, data scope and API access policy | Custom tools, API-based tool definitions and connection testing against internal endpoints | REST API design, identity and service accounts, SSRF and network policy awareness |
| Security review | Risk acceptance, SSO and access model decisions, and sign-off on the security test results | Hardening configuration, SECRET_KEY and SSRF proxy setup, and remediation of findings | Application security, TLS, identity protocols, secrets management |
| Runbook writing | Final ownership of runbooks, escalation paths and incident contacts | Draft runbooks for install, upgrade, backup, restore and key rotation | Technical writing, operations knowledge, familiarity with the deployed stack |
What usually goes wrong
Each card names a failure that typically affects a self-hosted Dify rollout and the step that prevents it. Settle these items in the written scope before build starts.
Knowledge base rebuild underestimated
Dify YAML DSL exports carry app configuration, workflow nodes, prompts, model parameters and knowledge base connections, but not document content, third-party API keys or usage logs. Teams budget for the import and forget that every knowledge base must be re-ingested and every provider key re-entered. Inventory source documents and keys for each knowledge base before work starts, and include re-ingestion in the fixed scope.
SECRET_KEY changed after deployment
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so changing it after deployment logs out every user. This often happens during a routine .env edit or when a host is rebuilt without carrying the value over. Generate the key once, store it in your secrets manager, and make the restore runbook and every upgrade checklist confirm it is unchanged.
Infrastructure chosen from defaults
The Compose minimums of 2 CPU cores and 4 GB of RAM start the stack but do not show what your users will need. Teams also choose the vector store and file storage after the first apps are built, then re-platform knowledge bases later. Size the host from expected concurrency, document volume and workflow load, and fix the metadata database, vector store and object storage in the scope before build.
Outbound model calls blocked by the proxy
The SSRF proxy blocks internal and private IP ranges, and the 1.16.1 release notes describe agent sandbox isolation through a Squid proxy. A model endpoint on a private address, a self-hosted model server or an internal API tool can then fail or route unexpectedly. List every outbound destination the apps need, test each one through the proxy settings in staging, and record each exception as a reviewed change.
Multi-tenant use without authorization
The Community edition is limited to one workspace, and the Dify Open Source License forbids operating a multi-tenant environment, where one tenant is one workspace, without written authorization. The license also bars removing the logo or copyright information from the console. Teams that give separate departments or customers their own workspace find this out late. Confirm the workspace count and branding terms in writing before the scope is signed.
Nobody owns monthly releases
Dify minor releases have arrived roughly monthly, including 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Each upgrade calls for a backup, the target version's upgrade guide and a check of .env.example for new variables. Without a named owner, the stack drifts behind and later upgrades become harder. Assign an owner and a monthly review in the support scope.
How the work changes by starting point
A single virtual machine running Docker Compose is the smallest scope. The stack starts the api, worker, web and plugin daemon services along with PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. The work centers on sizing the host, TLS, backups and a documented upgrade routine.
- Dify's documented minimum is 2 CPU cores and 4 GB of RAM, but a pilot with real document loads needs more. Confirm sizing against expected usage.
- Confirm that Docker Compose 2.24.0 or later is available on the approved operating system image.
- A single node has no high availability. Confirm the owner accepts that for the pilot.
- Confirm the backup target and run a restore test for the database and file storage.
- Confirm who owns the SECRET_KEY value and TLS certificate renewal.
Kubernetes is chosen for high availability, and Dify Enterprise is the product path on that platform. Dify's Enterprise resources checklist lists 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. Choosing between Community on Compose and Enterprise on Kubernetes is a commercial and scope decision as well as a technical one.
- Enterprise is custom priced, so the quote depends on the license, edition and support terms. Request it in writing.
- Confirm cluster and Helm versions, and whether the platform team operates ingress, storage classes and backups.
- Confirm whether Qdrant replaces the default Weaviate, and who will run a clustered vector store.
- The checklist's production example uses six worker nodes with 8 CPUs and 32 GB of RAM each. Treat it as Dify's reference point and size with the owner.
When the platform already provides PostgreSQL and an S3 standard, Dify has to use them. Dify supports PostgreSQL as its metadata database and S3-compatible storage for files, so the work shifts toward configuration, access and operations, with less building. Most of the effort moves to database ownership, credentials and backup alignment.
- Confirm a dedicated database and role for Dify. If Enterprise is chosen, confirm the PostgreSQL version meets the checklist's 14 or later requirement.
- Confirm whether the vector store can share PostgreSQL through pgvector, or whether knowledge bases need a separate store.
- Confirm bucket policy, encryption and lifecycle rules for uploaded documents, and that the Dify containers can reach the S3 endpoint.
- Confirm that the backup schedule captures the database and file storage together so that restores stay consistent.
In a restricted network, planning centers on what Dify can reach and what it can pull. Container images, plugin packages and model endpoints must be available inside the boundary, and outbound requests pass through the SSRF proxy, which blocks internal and private IP ranges. Model endpoints on private addresses need a deliberate design.
- Confirm the image registry mirror and the process for pulling each new release, since upgrades bring new images.
- Confirm which model providers are reachable, and whether any endpoints sit on private ranges that the SSRF proxy will block.
- Confirm how plugins are installed and whether they fetch packages from outside the boundary.
- Confirm sandbox network isolation with the security team. The Dify 1.16.1 release notes describe agent sandbox isolation through a Squid proxy.
Teams already building in Dify Cloud add a migration phase on top of the install. YAML DSL export covers app configuration, workflow nodes, prompts, model parameters and knowledge base connections, but it does not carry third-party API keys, knowledge base content or usage logs. The full procedure is covered in the Dify migration topic.
- Confirm the number of apps and workspaces in scope, since the Community edition is limited to a single workspace.
- Confirm who will re-enter API keys and where they will be stored.
- Confirm that knowledge bases will be rebuilt from source documents, and who owns those sources.
- Confirm the target starting point (Compose or Kubernetes) before exporting, so the import target is fixed.
What you need to provide
Most of the schedule risk in a self-hosted Dify rollout sits on the client side, and it is decided before any installation begins. The team needs the infrastructure target settled first: cloud accounts or cluster access, either Docker hosts or a Kubernetes namespace, DNS names and TLS certificates for the console and the API. Each of these depends on someone outside the project, such as a network or platform team, so request them at scoping rather than at build time.
Identity and model access are the two items that most often block the schedule. Name the owner of the identity provider and agree which accounts will sign in to the console, because SSO settings and redirect URLs cannot be tested without them. Model provider accounts also need a named approver who has signed off on sending company data to each provider. Confirm that approval, the billing owner and the API key handling process in writing before the first workflow is built.
Each first app needs a named business owner who can answer questions about expected behavior and sign off on test results. Ask the client to supply sample documents and data for each knowledge base early, and to say whether any of it is restricted. Document content is not carried over by an app export, so the knowledge base build depends on this material arriving on time.
Three platform decisions also belong on the client list: the vector store, the object storage target, and where secrets live. Confirm the secret store for database passwords, provider keys and SECRET_KEY, and agree who holds the value of SECRET_KEY, since changing it after deployment logs out all users. Finally, book a change window for go-live and any cutover from a previous tool. Confirm the exact vector store and storage options with your platform team, since they depend on the database and storage you already operate.
Questions buyers ask before hiring help
How much does a self-hosted Dify implementation cost?
The cost is the services work plus the infrastructure you run, because the Community edition license is free. Enterprise is custom priced and quoted from written scope. The published Dify Cloud prices of 590 US dollars per year for Professional and 1,590 US dollars per year for Team are subscription prices for the hosted service, so they do not include the cost of hosting Dify yourself. Ask for a quote with separate lines for discovery, build, testing, handover, and any recurring support or upgrade retainer.
Is the Dify Community edition free to self-host?
Yes, the self-hosted Community edition is free and limited to a single workspace. Multiple workspaces, SSO, advanced security, a commercial license and professional support belong to the Enterprise edition, which is custom priced. The Dify Open Source License also prohibits operating the source code as a multi-tenant environment without written authorization and prohibits removing the logo or copyright information from the console, so confirm those terms before you offer Dify to outside users.
How long does a Dify implementation take to deliver?
Duration depends on the written scope, so no general timeline applies. The main drivers are the deployment target, the number of apps and knowledge bases, the data sources to connect, whether SSO and an external vector store are in scope, and how many people must review and approve each stage. Ask for a timeline with milestones, the client actions each milestone depends on, and the review cycles included in the price.
What does a Docker Compose Dify deployment need from our servers?
The Docker Compose docs set a minimum of 2 CPU cores and 4 GB of RAM, with Docker Compose 2.24.0 or later. That minimum is a floor for a test install, not a production sizing. Production sizing depends on concurrent users, workflow run volume, model latency, knowledge base size and the vector store you choose. The Enterprise resources checklist describes a larger production example with six worker nodes, each with 8 CPUs and 32 GB of RAM, plus a three-node Qdrant cluster. Treat that as an Enterprise reference, and size your own environment from load tests.
Can our own team deploy and run Dify without a partner?
Yes, if your team has the skills listed on the in-house version of this page. Those include container or Kubernetes operations, PostgreSQL and Redis administration, object storage, reverse proxy and TLS setup, secret handling and model provider administration. Plan for ongoing work as well, since Dify ships minor releases about monthly and the docs ask you to back up before every upgrade and check .env.example for new variables. Compare that recurring effort with your team's capacity before you decide.
What does our organization need to provide before a Dify project starts?
The client provides named owners for scope decisions, hosting accounts or cluster access in its own infrastructure, and accounts with each approved model provider. It also provides document sources for knowledge bases, identity provider details if SSO is in scope, and contacts for security review and change approval. The written scope should list each client input, the person responsible for it and the date it is needed, because late inputs are a common cause of schedule changes.
How DeployOpen scopes and delivers Dify
DeployOpen plans, implements, hardens, documents and supports self-hosted Dify inside your own cloud accounts, data centers or air-gapped networks. The scope is agreed in writing before any build work, so the plan and cost follow from decisions you can review.
How we scope
- We confirm whether Community Compose or Enterprise on Kubernetes fits your availability, identity and workspace requirements.
- We record the database, vector store and object storage choices, with the reasons for each, in the written scope.
- We list the model providers, first apps and knowledge bases in scope, so cost drivers are visible before the quote is final.
How we build
- We install Dify in your environment and configure the metadata database, file storage and SECRET_KEY handling.
- We set up model provider credentials, outbound SSRF proxy rules and the sandbox settings agreed in the scope.
- We build the first apps and knowledge bases, then test retrieval, access and agent network isolation against the plan.
How we hand over
- We document the deployed architecture, configuration values, secret locations and backup procedure for your operators.
- We provide a tested backup and restore run, with the results recorded as evidence for your team and assessors.
- We walk your engineers through upgrade steps, including backups before each version change and checking new .env variables.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live, scoped separately in writing.
- We can plan monthly minor release upgrades against the release notes and per-version upgrade guides your team approves.
- Confirm with us which support, response and testing terms apply, since these are set in the retainer agreement rather than assumed.
