Dify
Dify is an AI application platform for product and engineering teams that need to build, deploy, and operate agents, chat applications, and workflows from models, knowledge, and tools. A team can use Dify to operate a custom ecommerce assistant, but it must connect the relevant catalog or order systems, define action permissions, and maintain the deployment and model configuration.
Dify is an AI application platform for product and engineering teams that need to build, deploy, and operate agents, chat applications, and workflows from models, knowledge, and tools. A team can use Dify to operate a custom ecommerce assistant, but it must connect the relevant catalog or order systems, define action permissions, and maintain the deployment and model configuration.
Dify is an AI application platform for product and engineering teams that need to build, deploy, and operate agents, chat applications, and workflows from models, knowledge, and tools.
- Views
- 0
- Uses
- 0
- Favorites
- 0
- Supported Platforms
- Web · API · Self-hosted · Docker
Buying view: Dify suits technical teams that want a visual application layer for RAG, agents, workflows, model choice, and observability, with cloud or self-hosted deployment. Self-hosting removes neither model charges nor the work of securing credentials, monitoring runs, backing up data, and applying upgrades.
Capabilities
Dify is a platform for building AI applications, not a finished support or marketing tool. Teams can create conversational assistants, structured workflows and task-driven Agents by configuring models, knowledge, tools and execution logic. What an app can do depends on that design and the systems it is allowed to access.
Choose what kind of app to build
A structured task, an ongoing conversation and an open-ended assignment call for different controls. These are ways to build in Dify, not separate subscription packages.
Workflow
Build a process for jobs such as document processing or report generation. It starts from user input or a configured trigger; the team defines the nodes, branches and outputs, and can delegate selected steps to an Agent.
Workflow and Chatflow ↗Chatflow
Build an assistant that people can keep talking to. Each message runs through the configured flow before a reply is returned; conversation context can carry across turns. Unlike Workflow, it does not start from scheduled or event triggers.
Workflow and Chatflow ↗Agent
New · BetaConfigure a reusable AI worker with a model, instructions, skills, files and tools. It can work in its own sandbox as a chat app, or handle a task inside a Workflow. Its actions adapt to the task rather than following a fully prewritten sequence.
New Agent overview ↗Dify also retains simpler Chatbot, Text Generator and Legacy Agent app types. A classic Agent node selects from configured tools; the new beta Agent adds a separately managed worker and sandbox. They are not interchangeable.
Combine the capabilities the task needs
The team chooses which capabilities to include and how they connect. An app does not need every block below, and an Agent does not call every available tool on every run.
User Input & Triggers
Collect a message, form fields or files as input. Workflow can also start on a schedule, an integration event or a webhook; the external event and its data must be configured. Chatflow starts from a user message.
Workflow triggers ↗LLM & Agent
Use an LLM node for a defined generation or analysis step. A classic Agent node can decide which configured tool to call and use its result to continue the task; the builder sets instructions and execution controls. The new beta Agent can also be reused in a Workflow node.
Agent node ↗Knowledge & Retrieval
Prepare product documentation, policies or other reference material in a knowledge base, then retrieve relevant passages for an app. The team manages the documents and tests retrieval; adding a knowledge base is not the same as training a model or connecting live order data.
Knowledge bases ↗Branches, Iteration & Loop
Define which steps run in sequence or in parallel, which branch a condition selects, and which work repeats. Iteration processes items in a list; Loop repeats a group of steps under a configured condition. These controls belong to the authored flow, not an assumed AI decision.
Orchestration logic ↗Tools, APIs & MCP
Connect services through tool plugins, custom OpenAPI tools or HTTP-based MCP servers. A User Input Workflow can become a reusable tool for another app; Chatflow cannot. Available actions depend on the connected service, credentials and granted permissions.
Tools and external services ↗Human Input
Add a form where a person needs to review content, edit it or choose the next route. The run pauses at that configured node, then follows the response or timeout path. Human review is not automatically added to every Agent action; trigger-started workflows cannot deliver the form through a web app.
Human Input ↗From building an app to running it
This is the team's delivery process, not the execution path of every app. Test results and live logs help the team revise its configuration and publish another version when needed.
- Create app
Choose the app type for the intended interaction: a task, a conversation or an Agent assignment.
- Configure logic
Set the model and instructions, connect the required data and tools, and define the flow or Agent capabilities.
- Test the app
Try sample inputs and inspect intermediate results. Workflow supports node or whole-flow testing; the new Agent has a separate Preview mode.
- Publish version
Publish the chosen configuration. Depending on the app type and entry point, provide a web app, embed or API access, or enable published triggers.
- Review live runs
Inspect conversations or runs, feedback and execution details. For Workflow and Chatflow, editor tests are separate from production usage logs.
Case 1: Build a store support assistant
A store's support team repeatedly answers questions about product specifications, delivery and returns. This assistant puts those answers in a website conversation. It first answers from store documents; a separately connected order lookup can also explain an individual order's current status.
What the team prepares
Operations prepares current product documents, delivery and returns policies, common questions with approved answers, and a support contact link. The Dify workspace also needs a configured language model. A technical colleague handles website embedding and, if order lookup is needed, a store API: a controlled connection through which the assistant requests permitted order information.
Build it step by step
Create a conversation and define its job
The builder creates a Chatflow and follows the official support tutorial. Each box on its canvas is one processing step. Operations defines the assistant's role and reply style, then writes rules such as answering from store materials, asking for missing information and directing requests for a refund decision to the support team. These instructions guide replies; they do not grant access to orders.
Give the assistant the store's reference material
The builder creates a knowledge base, uploads the prepared documents and connects a Knowledge Retrieval step. This step finds passages relevant to the customer's question. Operations tests questions such as whether a product can be machine-washed or whether opened goods can be returned, then checks that the retrieved passages contain the correct policy. Missing or outdated information is corrected in the documents before testing again.
Send different questions to the right route
A Question Classifier step sorts messages into product or policy questions, order questions, and requests for a person. Product and policy questions go to knowledge retrieval, then to an LLM step that writes a reply from the retrieved text. An Answer step displays it in chat. The human-support route displays the team's contact link; a connected helpdesk would be an additional integration.
Connect order lookup when the store needs it
For order questions, a Parameter Extractor step identifies the order number in the message; if it is missing, the assistant asks for it. A technical colleague connects HTTP Request to the store's lookup API and maps its returned status into the reply. The store service must check that the signed-in customer is allowed to view that order; an order number alone is not authorization. Until that connection is ready, this route directs the customer to the existing order-tracking page or support contact.
Write the normal reply and the missing-information reply
Operations specifies what a useful reply should contain: the product fact or order status, the applicable store policy and a clear next action. The builder also connects fallback routes for no useful reference, no matching order and a failed lookup. Those routes explain what could not be confirmed and offer the support contact. Live shipment details can appear only when the connected service actually returns them.
Test real questions, then publish the website chat
Operations checks familiar questions, missing order numbers, unavailable orders and requests outside the assistant's remit in Preview. A technical colleague separately tests customer access to order records. After corrections, the builder publishes the app and gives the website maintainer its embed snippet. Once it is in use, the team reviews conversation logs and updates documents or reply rules where customers still get stuck.
Illustrative store scenario
For example, a shopper asks whether an opened item can be returned. The assistant retrieves the store's returns policy and explains the applicable conditions. If the shopper then asks about an existing order, the order route requests the missing identifier and uses the authorized lookup when available. If the shopper wants a refund approved, the assistant provides the configured support contact; it does not report that a refund has been completed.
What the team has after setup
The team gets a website assistant with documented-answer routes, an optional authorized order lookup and a clear contact route for unresolved requests. Operations owns the source material and reply rules; the technical team owns store access and the website connection. Refunds, cancellations and automatic helpdesk tickets would each require their own configured action and permissions.
Case 2: Build a WooCommerce order review workflow
An operations team needs to spot orders that deserve attention before taking the next fulfilment step. This example receives a new-order event from WooCommerce, checks the supplied information and sends a review request when the store's conditions are met. The operator receives an order summary and a reason to investigate, then handles the order in the store system.
What the team prepares
The store administrator prepares WooCommerce REST API access and credentials allowed to manage webhooks. A webhook is the notification the store sends when an event occurs. Operations defines which orders need review and names the receiving colleague. Dify also needs a language model and a working email setup for review links and follow-up notifications; self-hosted teams check their deployment's email configuration.
Build it step by step
Connect WooCommerce and choose the starting event
The builder creates a Workflow and installs the WooCommerce Trigger published by langgenius. Following its setup guide, the administrator enters the store address and credentials, then subscribes to order_created, meaning a new order was created. The plugin creates the store notification connection and checks incoming signatures. This first version uses new orders only; subscribing to updates later also requires deciding how repeated review requests will be handled.
Check what information arrives with an order
The team uses a test order to inspect the trigger's output. The builder passes the available order number, line items, amount, payment status and address information to the relevant later steps. Operations checks that information against the corresponding information in WooCommerce. A field that is absent is marked as missing. If a later check needs extra information, a technical colleague must connect a separate lookup before the workflow can use it.
Set the store's review rules, then add an AI summary
Operations defines concrete conditions, such as a missing required shipping field or an amount above the store's own review threshold. The builder uses If-Else, a condition-based branch, to route these orders for review. An LLM step receives the available order details and the matched rule, then writes a summary of what happened and what needs checking. A flagged order is a request for investigation, not proof of fraud or a failed payment.
Send an email review form to the responsible person
The review branch connects to Human Input, a step that pauses the run for a person's response. The builder puts the order number, summary and reason for review into a form and selects email delivery to the responsible colleague. Operations defines choices such as continue follow-up, ask the customer for information or handle manually. Each choice needs its own connected next step. Trigger-started workflows cannot deliver this form through a Dify web app.
Make every response lead to a clear follow-up
The builder connects an Email tool, with the team's sender account configured, to send routine order summaries to the internal mailbox. After review, the same channel can notify the assigned colleague of the decision and include a draft message if the customer needs to supply information; that colleague reviews and sends it. The Human Input timeout route sends an internal reminder and ends the run without approval. Failed data requests also route to a notification instead of producing a fabricated result.
Test each route and turn on the published workflow
The team tests an ordinary order, an order matching a review condition and one with missing information. It checks each review choice, email receipt and the configured timeout route. Once any issues have been corrected, the builder publishes the Workflow and enables its trigger. Operations then checks run logs to distinguish a request awaiting review from a completed notification, and adjusts the store's rules when they flag the wrong orders.
Illustrative store scenario
For example, a new order's amount exceeds the store's review threshold. The workflow identifies the matching condition, summarizes the order and emails the reviewer a form link. The reviewer checks WooCommerce and chooses to request more information. The workflow emails the responsible colleague that decision and a draft inquiry; the colleague contacts the customer and continues handling the order. If no reviewer responds before the configured deadline, the timeout route sends a reminder rather than approving the order.
What the team has after setup
The team gets a repeatable path from new-order notification to rule checks, a review decision and an internal follow-up message. Staff still fulfil, cancel or refund orders in WooCommerce. A pause in Dify does not place the store order on hold. Automating any store change would require a separately connected action and confirmation from WooCommerce that it succeeded.
Commercial plans
Estimated from published pricing rules
Dify subscription budget
Independent Vendolune budget matching based on public subscription prices; not a vendor calculator.
Monthly subscription budget
Select the highest eligible plan within this budget. Usage needs are not assessed.
Subscription scope
Dify
One Dify Cloud workspace, with each plan's fixed member, app and knowledge limits. Self-hosted software and Enterprise are separate offers.
Taxes and model-provider charges incurred when you use your own API keys are excluded. Message credits are a limited model-testing allowance, not unlimited model usage. No separately priced capacity packs are assumed; unused budget does not increase the plan's quotas.
View official pricing detailsOne Dify Cloud workspace, with each plan's fixed member, app and knowledge limits. Self-hosted software and Enterprise are separate offers.
Dify plan entitlements
One Dify Cloud workspace, with each plan's fixed member, app and knowledge limits. Self-hosted software and Enterprise are separate offers.
| Plan / add-on | Allowances and feature entitlements |
|---|---|
| Sandbox | 1 workspace; 1 member; 5 apps; 50 MB knowledge storage. Included plan entitlements
|
| Professional | 1 workspace; 3 members; 50 apps; 5 GB knowledge storage. Included plan entitlements
|
| Team | 1 workspace; 50 members; 200 apps; 20 GB knowledge storage. Included plan entitlements
|
Self-hosted and enterprise
| Product or sales surface | Scope | Public price and status |
|---|---|---|
| Community | For open-source, personal, and non-commercial self-hosted projects. Included plan entitlements
| Free software; infrastructure not included |
| Enterprise | For organizations requiring security, governance and dedicated support. Included plan entitlements
| Custom quote |
Comparable tools: price and workflow
| Tool | Workflow difference | Official public price reference |
|---|---|---|
| Botpress | Botpress: Visual and code-extensible AI agent builder for custom support and commerce workflows. Dify: Self-hostable visual LLM application platform for RAG chatbots, agents, and workflows. | $0/month + AI spend |
| n8n AI Agents | n8n AI Agents: Build self-hosted AI agent workflows with visual nodes, code, and API integrations. Dify: Self-hostable visual LLM application platform for RAG chatbots, agents, and workflows. | Free software (infrastructure not included) |
| Zowie | Zowie: Enterprise customer-facing AI with deterministic policy execution and cross-channel observability. Dify: Self-hostable visual LLM application platform for RAG chatbots, agents, and workflows. | Custom per-conversation quote |
| Fin | Fin: Intercom AI customer-service agent that can connect to an existing help desk and is priced per resolved outcome. Dify: Self-hostable visual LLM application platform for RAG chatbots, agents, and workflows. | $0.99/outcome |
| Make AI Agents | Make AI Agents: Build visual AI agent workflows across 3,000+ apps with drag-and-drop simplicity. Dify: Self-hostable visual LLM application platform for RAG chatbots, agents, and workflows. | $0/month; up to 1,000 credits/month |
Frequently asked questions
How does Dify fit into an ecommerce workflow?
A builder connects documents or structured data to a retrieval pipeline, lays out model calls, branches, and tools on a workflow canvas, and publishes the result as a web app or API. Logs, traces, and annotations provide the evidence needed to inspect failures and tune the application.
How is Dify priced?
The public price references shown here are Cloud Sandbox: Free; Cloud Professional: $590 per workspace/year; Cloud Team: $1,590 per workspace/year; Community self-hosted: Free software.
What should I keep in mind when self-hosting Dify?
Self-hosting does not eliminate model charges or the work of securing credentials, monitoring runs, backing up data, and applying upgrades.
Native connections
Cybozu's kintone plugin lets Dify workflows retrieve, create and update app records. Configuration requires the kintone domain, app ID and an API token with permission for the selected actions; record fields must match the target app.
kintone connectionSources
- Dify official product page
- Dify workflow application guide
- Dify plans and pricing
- Dify official pricing
- kintone connection
- Official workflow guide 1: Run a tested, published content workflow
- Official workflow guide 2: Run a tested, published content workflow
- Workflow and Chatflow
- New Agent overview
- Build an Agent
- Knowledge bases
- Tools and external services
- Test and enable workflow triggers
- Send a review form with Human Input
- Orchestration logic
- Publish applications
- Conversation and run logs
- Knowledge-based support tutorial
- Workflow Studio
- Official support Chatflow tutorial
- Build, test and embed a website assistant
- Connect external data with HTTP Request
- Extract information from a message
- WooCommerce Trigger by langgenius
- Route work with conditions
- Email sending plugin
User reviews
Content checked: