Building an AI assistant that answers from your own documents usually means writing the same plumbing twice: once for the retrieval logic, and again for the endpoint your product calls. Dify packages both into a visual canvas, and once your app works in the browser it is also available as a REST API, an embeddable widget, and an MCP server.
This guide walks through that full path in Dify Cloud: connect a model, turn your files into a knowledge base, ground a chatbot on it, then publish it and call it from your own backend. Every step below is compiled from current Dify documentation rather than from a hands-on session, so treat the exact button labels as the ones to look for in the interface you are working in.
Dify’s building blocks: apps, nodes, and knowledge
Dify offers several application types, and the difference matters before you begin. A Workflow runs a fixed sequence and returns a result through an Output node. A Chatflow is the conversational variant and ends with an Answer node. A Chatbot is the simplest conversational form, and the one this guide uses because its knowledge integration path is shortest.
Every app is assembled from nodes on a canvas. A User Input node collects what the visitor typed, a Knowledge Retrieval node searches your documents and passes matching passages downstream, an LLM node turns those passages plus the question into an answer, and an Answer node returns the result. Dify’s documentation also covers a larger catalog of nodes for branching, looping, code execution, HTTP calls, and tool use, which you can add later without restructuring the app.
Set up Dify Cloud and connect a model provider
Start at cloud.dify.ai and create a free account. New accounts begin on the Sandbox plan, which Dify’s quick start describes as free to start and includes 200 AI credits for calling models from providers such as OpenAI, Anthropic, and Gemini. Those Sandbox credits are a one-time allocation rather than a monthly refill, so plan your trial accordingly.
- Open the Model Provider settings. Go to Integrations > Model Provider and install the provider you want to use, such as the OpenAI provider.
- Set a default model. In the top-right corner of the Model Provider page, click Default Models and choose the model your app should use by default.
- Decide between included credits and your own key. Dify’s documentation states that no API key is required for models covered by your AI credits, and that you can instead configure your own API key. If you use your own key, store it in your password manager rather than in a note or a chat transcript.
You should see the selected model listed as the default on the Model Provider page. If it does not, the LLM node will report that no model is available, and every later step will fail for the same reason.
Create a knowledge base and ground a chatbot on it
The knowledge base is where your source material lives. Dify’s documentation describes four ways to start one: uploading local files, syncing data from Notion, syncing data from web pages, or creating an empty knowledge base.
- Create the knowledge base. Go to Knowledge, choose Create, and select Create a ready-to-use knowledge base.
- Bring in your files. Upload local documents, or connect a Notion workspace or website as a data source.
- Set the chunking options and preview the result. This stage splits long texts into smaller chunks. The documentation describes a preview step, so check that chunk boundaries look sensible before you continue.
- Choose the index method and retrieval settings. When a user query arrives, the knowledge base searches its documents using the retrieval method you selected here and extracts the relevant chunks.
- Wait for processing to finish. Dify’s own walkthrough ends this stage with a “data processing complete” step, because retrieval quality depends on the documents actually being indexed.
Next, attach that knowledge base to a chatbot. In Studio, create an application and select Chatbot. Open the Context section, click Add, and pick the knowledge base you just created. From there you can narrow search with metadata filtering, tune the retrieval setting under Context Settings, and switch on citation and attribution in the add-features panel so answers point back to their sources. Then open Debug and Preview and ask a question that only your documents can answer. If the preview returns the right passage, the retrieval side is working.
If the preview answers from general knowledge instead of your documents, the knowledge base was not attached or the retrieval setting is too narrow. Re-check the Context panel before debugging anything else.
Publish the app and call it from your backend
Publishing is where Dify earns its keep. Dify’s publishing overview lists four outputs: web apps, APIs, website embeds, and MCP servers.
- Publish the current version. Click Publish in your app. The documentation warns that publishing replaces the live app with the current configuration, so users see the change on their next interaction.
- Grab the web app link if you just need a shareable page. The link sits on the app’s Access Point tab, and web apps are generated automatically for every app.
- Create an API key from inside the app. The key is scoped to that one app, and one key serves all of your end users. Dify’s guidance is explicit that the key belongs in your backend only, because a key embedded in frontend code or a client app can be extracted and abused.
- Send the key as a Bearer token. For Dify Cloud the base URL is
https://api.dify.ai/v1; for a self-hosted deployment you use your own instance’s API base URL. A key check needs no code at all: open the Get App Info endpoint, click Try it, paste the key into the Authorization field, and press Send. The same call from a terminal looks like this:
curl https://api.dify.ai/v1/info \
-H "Authorization: Bearer $DIFY_API_KEY"A successful response returns the app’s name, description, tags, mode, and author name, which confirms both that the key works and which app it belongs to. The endpoint you call depends on the app type: Chatflow apps use advanced-chat, Workflow apps use workflow, Agent apps use agent, and Chatbot and legacy Agent apps use chat or agent-chat. Text generators use completion. A chatbot in this guide therefore sits behind the chat endpoint.
Two extra options are worth knowing about. Website embeds let you drop the same app into an existing site as a chat widget or an inline frame, which is useful when you want a self-service assistant without writing an interface. MCP server publishing, documented separately, exposes the app as an MCP server so tools such as Claude Desktop and Cursor can call it natively. The MCP feature is off by default and lives on the Access Point tab; Dify notes that the generated server URL contains authentication credentials, so treat it like an API key and regenerate it if it leaks.
Plans, limits, and where projects tend to stall
Dify’s pricing page separates hosted plans from the free self-hosted Community Edition. The figures below were checked on the official pricing page on 22 October 2026. Prices exclude applicable taxes.
| Plan | Price | What it includes |
|---|---|---|
| Sandbox | Free | 200 message credits, 5 apps, 50 knowledge documents, 50MB knowledge storage, 10 knowledge requests per minute |
| Professional | $590 per workspace per year | 5,000 message credits per month, 50 apps, 500 knowledge documents, 5GB storage, 100 knowledge requests per minute |
| Team | $1,590 per workspace per year | 10,000 message credits per month, 200 apps, 1,000 knowledge documents, 20GB storage, 1,000 knowledge requests per minute |
Two limits bite more often than the credit counters. First, knowledge operations are rate limited per minute and the ceiling depends on your plan; the Knowledge Retrieval node carries a note that retrieval operations are subject to those per-minute limits. If a burst of traffic starts returning errors during testing, the reason is usually the plan’s knowledge request rate rather than your code. Second, message credits are consumed based on the model type, and Dify’s pricing page states that once credits run out you can switch to your own API key.
Self-hosting is the other route. The Community Edition is free and includes the core features, and the quick start confirms you can self-host Dify and then follow the same steps on your own instance. The tradeoff is that you own the deployment, the model credentials, and the upgrades.
Where teams most often stall is not the build but the handoff. A common pattern is to finish the chatbot in the Studio, share the web app link, and only later discover that the product needs a different response shape or a stable endpoint. Building against the chat endpoint from the start, and keeping the API key in the backend rather than in the browser, avoids most of that rework.