TECHNOLOGY

Dify with a local LLM: connect a provider and build an app

In this article
THE QUICK TAKE

Dify manages providers at workspace level, while an explicit app or node selection can differ from workspace defaults.

To start a Dify app with a local LLM, configure the provider in the workspace first, then select that model in the app’s generation step. A workspace default and an explicit node selection are different sources of model choice.

The concrete application boundary

The current self-hosted documentation places provider management under Integrations > Model Provider. Workspace owners and administrators manage these providers. A provider may need installation of its integration before Setup exposes the required endpoint or credentials. Model availability depends on the chosen provider plugin rather than on a universal list of fields. Custom models can be added where that provider supports them; fixed-catalog providers do not necessarily offer Add Model. The workspace also has default models for different jobs. A successful language model connection does not configure embedding, speech, or reranking defaults, and those auxiliary components are unnecessary for a first text-only app (Dify documentation overview).

A practical route

In an existing local Dify workspace, open Integrations > Model Provider and choose the integration appropriate to the running local server. Install the provider if absent, click Setup, and enter the fields required by that integration. Validate the connection and add the actual model if supported and needed. Create a minimal text application or flow and explicitly select that model in its generation step. Use preview with a short input before adding tools, knowledge sources, or branching logic. In a flow, the LLM node selects the configured model and receives the supplied text through its prompt variables (Dify Model Providers).

A worked example

Build a draft helper that turns a fictional release note into a concise announcement. Supply the source text directly, ask the model to preserve limitations, and preview the response. Next change the source text while leaving the selected model unchanged. This verifies that the app receives its input and uses the intended generator without relying on a retrieval pipeline or external action (Dify LLM node).

CheckRecord
WorkspaceThe provider integration managed by the existing workspace owner or administrator.
Generation stepThe explicit local model selection in the app or flow.
PreviewThe supplied fictional text and the resulting announcement.

Reading the failure correctly

If one app works but another fails, inspect explicit model selections before rotating workspace credentials. A node without a chosen model can fall back to workspace defaults. Removing a custom model’s only credential can remove that model, so inspect the documented provider behavior before attempting a cleanup as a troubleshooting shortcut.

What completes the check

Keep the working preview and its explicit model selection. Add other app components only after this narrow path is clear. The provider setup belongs to workspace administration, while app instructions and input mapping belong to the app author.

Related background: A local RAG server: placing components around the GPU, llama.cpp server: a local API from a GGUF model.

← All articles