Where Dify fits in a private AI stack
Dify is a platform for building LLM applications: chat assistants, workflows on a visual canvas, knowledge bases for retrieval-augmented generation, and agents that call tools, MCP servers or your own APIs. Every app is exposed through an API and can be published as a web app. Self-hosting keeps app definitions, documents, conversation logs and provider credentials in your environment.
Dify does not run models. It calls hosted APIs or self-hosted runtimes such as vLLM and Ollama, often through a gateway such as LiteLLM. That makes it the layer where teams assemble prompts, documents and tools, and where data-handling rules for those apps are enforced.
License and edition terms that shape the deployment
Dify uses its own license built on Apache 2.0. Have counsel read the full text before designing a shared platform.
| Term | What the license or vendor states | Deployment effect |
|---|---|---|
| Multi-tenant condition | Without written authorization from Dify, the source code may not be used to operate a multi-tenant environment. One tenant is one workspace. | Separate workspaces per business unit or customer fall under this condition. Settle the workspace model early with counsel or Dify. |
| Logo and copyright | When the Dify frontend is used, its logo and copyright information in the console and apps may not be removed or modified. | Published web apps keep Dify branding. A custom frontend built on the app APIs is outside this condition. |
| Enterprise edition | Dify Enterprise adds SSO through OIDC, SAML and OAuth2 for the console and web apps, plus RBAC and vendor support. | If corporate SSO is a requirement, choose the edition before building production apps. |
Components in a Dify deployment
The Docker Compose file in the Dify repository defines these services.
API, workers and web
The Flask API serves the console and app APIs. Celery workers handle document indexing and background jobs, one beat service schedules tasks, and the web service serves the frontend behind Nginx.
Database and Redis
PostgreSQL by default, or MySQL, OceanBase or seekdb, holds accounts, apps, runs, logs and encrypted credentials. Redis is cache, task broker and event bus, with Sentinel and Cluster modes documented.
Vector store and files
Weaviate is the default vector store, with Qdrant, pgvector, Milvus, OpenSearch and others available. Files and workspace encryption keys sit on a volume or in object storage.
Sandbox, proxy and plugins
dify-sandbox runs Python and JavaScript code nodes. A Squid SSRF proxy carries outbound requests and blocks private ranges. The plugin daemon runs model provider and tool plugins.
Choose a deployment shape and size it
The official guide uses Docker Compose 2.24.0 or later with a minimum of 2 CPU cores and 4 GiB of RAM, and profiles select the database and vector store. It suits pilots and smaller deployments, where host backups and a tested restore carry the availability plan.
Community edition installs use community-maintained Helm charts, which you review and own. Run several API, worker and web replicas with one beat scheduler, and keep state in replicated PostgreSQL, Redis with Sentinel, an external vector store and object storage. Run migrations from one job per upgrade and set MIGRATION_ENABLED to false on API pods.
Mirror pinned images internally, including Nginx and Squid, which the Compose file tags as latest. Set MARKETPLACE_ENABLED to false and install reviewed plugin packages from files. Test plugin installs early, since they can fetch Python dependencies, and point providers only at internal endpoints.
Load comes from concurrent runs, long streaming responses, document indexing and embedding calls, vector store size and code executions. CELERY_WORKER_AMOUNT defaults to 4, so watch indexing queues during large uploads, and measure model endpoints separately.
Connect models and control what reaches them
Model providers install as plugins: Ollama has its own, and the OpenAI-API-compatible plugin can call vLLM or a LiteLLM gateway, which gives one place for keys, budgets and approved fallbacks. Knowledge bases also need an embedding model. Vectors from one embedding model cannot be searched with another, so changing it means re-indexing.
Prompt injection is the main application risk. Retrieved documents and tool outputs enter the model's context and can carry instructions. Give agents only the tools they need, put tools that write data behind narrow credentials or a Human Input step, and remember that anyone who can upload to a knowledge base can influence its answers. Decide log retention and whether traces may leave through integrations such as Langfuse.
Change the shipped defaults before go-live
From Dify's environment variable reference and release notes.
| Area | Default | Action |
|---|---|---|
| First-time setup | The install page creates the first admin. INIT_PASSWORD is optional. | Set INIT_PASSWORD so nobody else can claim the admin account. Keep ALLOW_REGISTER off. |
| SECRET_KEY | A sample value in the example file. | Generate it with openssl rand -base64 42 and store it in a secret manager. Changing it later logs out every user. |
| Shared secrets | SANDBOX_API_KEY is dify-sandbox, INNER_API_KEY_FOR_PLUGIN is public in the repository, and DIFY_AGENT_API_TOKEN (1.16.1) has an insecure default. | Replace each, plus database, Redis and vector store credentials, and keep paired values in sync. |
| Outbound access | The SSRF proxy blocks private ranges. SANDBOX_ENABLE_NETWORK is true. | Allowlist only the internal hosts tools need, and turn off sandbox networking unless code nodes need it. |
| Plugins and agents | Signature checks are on. Dify Agent (1.16.0) runs agents in one shared sandbox. | Approve plugins through review. Release notes say to offer Dify Agent only to trusted users. |
Backup, restore and upgrades
What needs to be backed up?
The database, file storage (which holds each workspace's private key under privkeys), plugin daemon storage, the vector store unless you accept re-indexing, and the .env and Compose files or Helm values. Take them together: credentials in the database cannot be decrypted without the matching storage.
How do we rehearse a restore?
Restore onto an isolated host at the same version, then call a model with a stored credential, query a knowledge base and run a workflow with a code node.
How do upgrades work?
Dify notes that steps vary by release. Back up, read every release note crossed, diff each .env.example against .env, and re-apply Compose changes to the new file. For example, 1.17.0 renamed EDITION to DEPLOYMENT_EDITION, and 1.17.1 required a staged upgrade of the bundled Weaviate.
Dify operating ownership
Dify sits between model owners, operators and app builders, so each part needs a named owner.
Platform team
- Runs services, data stores and the plugin daemon.
- Backs up database, storage and vectors together.
- Applies environment changes at each upgrade.
Model owners
- Approve providers, embedding models and routes.
- Decide which plugins and tools may be installed.
Security
- Holds SECRET_KEY and provider credentials.
- Reviews SSRF allowlists and published web apps.
- Tests agents for prompt injection.
App builders
- Own prompts, workflows and knowledge bases.
- Export key apps as DSL files into version control.
Dify deployment questions
Can the community edition use our identity provider?
OIDC and SAML SSO are Enterprise features. The community edition documents email and password, email code, and GitHub or Google sign-in.
Can each department get its own workspace?
The license counts each workspace as a tenant and requires written authorization from Dify for a multi-tenant environment. Review the model with counsel or Dify first.
How do we move apps between instances?
Apps export and import as DSL files. Provider credentials and knowledge base contents are set up separately on the target.
Scope and handover
Effort depends on the edition and workspace model, the number of model providers, knowledge base volume, availability targets and isolated network requirements. Agreeing data-handling rules for prompts, documents and logs often takes longer than installing the stack.
DeployOpen deploys Dify in your cloud account, data center or isolated network, connects approved model runtimes, replaces shipped secrets, configures the SSRF proxy and sandbox, integrates SSO where your edition supports it, and sets up backups with a restore rehearsal. We can also test published apps and agents for prompt injection as part of AI security testing.
Handover includes the edition decision, configuration in version control, the model and plugin register, the restore test record and named owners.
