Verified: September 2026 Beginner path

Dify Tutorial 2026: Build and Publish Your First Chatflow

This tutorial follows the current Dify interface from model setup to a published app. You will create a small Chatflow, connect its nodes, test real failure cases and learn where a knowledge base or self-hosted deployment fits.

Start the tutorial

What you will build

The result is a support Chatflow that accepts a question, passes it to a selected language model and returns the answer. That deliberately small path exposes the important Dify concepts without mixing in server administration or an oversized example.

Input

The built-in user query enters the Chatflow.

LLM node

A configured model receives the prompt and query.

Answer node

The model output is returned to the chat user.

Access point

The published version is exposed through a web app, API or embed.

Before you open Studio

Use Dify Cloud for the shortest path

The official quick start uses Dify Cloud. New Sandbox accounts may include one-time AI credits. They are not a recurring monthly allowance, so check the current workspace balance before relying on them.

Open Dify Cloud

Use your existing self-hosted instance

If Dify is already running on your server, the Studio steps below are the same. Installation, public URLs, secrets and backups are separate operational tasks.

Read the current Docker guide
Credential rule: do not paste a model-provider key into an app prompt, public client code or screenshots. Configure it only through the provider integration and apply the provider's own usage limits.

1. Configure a model provider

  1. Open Integrations, then Model Provider.
  2. Install the provider integration you intend to use.
  3. Use included credits when available or configure your own provider credentials.
  4. Open Default Models and choose a system reasoning model that is available in your workspace.

Model names and availability change. Choose from the models shown in your workspace instead of copying an old model name from a tutorial.

2. Create a Chatflow

  1. Go to Studio, open Workflow and choose Create from Blank.
  2. Under Orchestrate, choose New Chatflow, give the app a descriptive name and create it.
  3. Keep the existing start or user-input side of the canvas and add an LLM node.
  4. Add an Answer node after the LLM node.
  5. Connect the nodes so the query reaches the LLM and the LLM text reaches Answer.

Use Workflow instead when the app is a one-shot process with defined input and output rather than a conversation.

3. Prompt the LLM node

Select the model you configured, then write a short system instruction that defines scope and honest fallback behavior. Insert Dify variables through the variable picker rather than typing a guessed variable name.

You are a support assistant for Example Product.
Answer only questions about the product.
If the available information is insufficient, say what is missing.
Do not invent account, billing or security details.

In the Answer node, insert the actual LLM output variable from the picker. Clear names matter once the canvas contains more than a few nodes.

4. Test before you publish

Open Preview and test more than a friendly demo question. A useful first check includes:

  • one normal question that is clearly in scope;
  • one question outside the app's scope;
  • one request whose answer is not present;
  • one prompt that attempts to override the system instruction;
  • one long or malformed input.

Inspect the last-run details when a node fails. Change one thing at a time, then repeat the same inputs so you can tell whether the prompt or node configuration improved.

5. Publish and choose an access point

  1. When Preview behaves as expected, choose Publish, then Publish Update.
  2. Open the app's access point to use the hosted web app, API or website embed.
  3. After every later canvas change, publish a new update before testing the live version.

Keep server-side API credentials out of browser code. If you call the app API from a product, place the credential behind your own authenticated backend and add rate limits appropriate to the use case.

6. Add a knowledge base only when the app needs one

A knowledge base is useful when answers must come from documents that exceed the model context or change independently from the app. It is not a substitute for testing retrieval quality.

  1. Configure an embedding model supported by your chosen provider.
  2. Go to Knowledge, create a knowledge base and add the source documents.
  3. Review chunking and retrieval settings, then run Retrieval Testing with representative queries.
  4. Add a Knowledge Retrieval node to the Chatflow and select the knowledge base.
  5. Pass the retrieval result into the LLM node as context, then test both present and missing answers.

Inspect poor retrieval results before changing the prompt. A missing or badly split source cannot be repaired by asking the model to sound more confident.

Choose where Dify should run

Finish the app in Cloud first if you are still learning the product. Choose a managed deployment when you want help with operations. Choose a VPS when you are prepared to own updates, backups, TLS, monitoring and incident recovery.

Affiliate disclosure: The provider links below are sponsored. We may earn a commission if you buy through them, at no extra cost to you.

Check Hetzner VPS options Check Hostinger VPS options Check managed Elestio options

Compare operational responsibility in the self-hosting guide before choosing a provider.

Official references used for this tutorial

Continue with workflows Connect through the API