How a self-hosted Dify connects to model gateways, observability tools, external knowledge systems, MCP clients and servers, and document sources, using only the methods the Dify docs and official marketplace plugins describe.
Routing every Dify model call through a self-hosted LiteLLM proxy with the official LiteLLM plugin: base URL, virtual or master keys, model aliases, and why a gateway helps with spend tracking, budgets and fallbacks across providers.
Connecting Dify to models served in your own infrastructure through the official OpenAI-API-compatible plugin, covering LLM, embedding, rerank, speech-to-text and text-to-speech endpoints, context and token settings, and workspace default models.
Sending Dify workflow, chatflow and message traces to a self-hosted Langfuse project: creating project keys, configuring tracing per app, the trace fields Dify exports such as token counts and node executions, and when OpenTelemetry or other tracing backends fit better.
Keeping documents in your own retrieval service or a managed knowledge base and letting Dify query it through the External Knowledge API: the retrieval endpoint contract, bearer key handling, top K and score thresholds, SSRF proxy allowlisting and what Dify cannot manage.
Both directions of Model Context Protocol in Dify: importing tools from HTTP MCP servers with OAuth dynamic client registration or custom headers, and exposing a Dify app as an MCP server for clients such as Claude Desktop or Cursor, with the credential handling each needs.
Feeding Dify knowledge bases from the document sources teams already use: Notion internal or public integrations configured in .env, the Google Drive data source plugin for knowledge pipelines, website import, what each import drops and the embedding cost of re-syncing.
Sending Dify workflow and chat traces to LangSmith: project and API key setup per app, what each trace contains, and how this compares with self-hosted tracing for teams that cannot send prompts to a SaaS service.
Tracing Dify apps into Arize Phoenix, which can run inside your own network: connecting the project endpoint and key, reading node level spans, and keeping prompt data in infrastructure you control.
Connecting Dify app tracing to Opik, either a self-hosted Opik server or Comet's hosted service: workspace and project settings, the trace fields Dify exports, and when Opik is preferred over Langfuse.
Giving Dify agents and workflows web search without a commercial search API by pointing the SearXNG tool plugin at a SearXNG instance you run, plus the SSRF proxy allowlisting this needs when SearXNG sits on an internal host.
Letting Dify agents read Confluence pages and work with Jira issues through the official tool plugins: credentials per workspace, what the agent can and cannot change, and why indexing Confluence into a knowledge base is a different job.
Feeding Dify knowledge pipelines from GitHub repositories and S3 buckets with the official datasource plugins: repository issues, pull requests and wiki pages, bucket access with scoped IAM credentials, and keeping indexes current.
Running Dify workflows from Slack events with the Slack trigger plugin and replying through tools: event subscription, the public trigger URL a self-hosted instance must expose, and per-channel scoping.
Improving how Dify reads PDFs, slides and email files: the built-in ETL versus ETL_TYPE set to Unstructured, the Unstructured and MinerU tool plugins inside knowledge pipelines, and running the extraction service in your own network.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.