The idea in plain English
A customer should feel like they are using our AI automation platform. They create agents, drag workflow nodes, connect company systems, add knowledge and run automations. Underneath, Dify does the heavy execution work.
We own the experience
Branding, page structure, workflow editor, settings, templates, onboarding and permissions are ours.
Dify owns the heavy runtime
Instead of writing an agent/workflow execution engine from scratch, we delegate execution to Dify.
Systems stay pluggable
LLMs, company APIs, MCP servers, tools and knowledge sources sit behind the runtime.
What exactly are we building?
The simplest way to divide the work is: customer-facing product layer vs execution layer.
WE BUILD THIS
- Our login, branding and navigation
- Agent creation screens
- Visual drag-and-drop workflow editor
- Knowledge-base management screens
- Connections / credentials UI
- Templates and starter workflows
- Human-friendly run history and error screens
- Role/permission rules appropriate for our customers
- Deployment/updater tooling for each customer
DIFY ALREADY DOES THIS
- Execute workflow graphs
- Run LLM and agent nodes
- Manage model-provider connections
- Run RAG / knowledge retrieval
- Execute tools and plugins
- Handle node variables and outputs
- Track workflow runs and traces
- Publish and execute applications
- Maintain internal workflow definitions
What happens when a user drags a node?
This is the most important engineering flow for the team to understand.
Canvas state
Our UI stores nodes, positions, connections and friendly labels.
Translate
Our adapter converts our friendly graph schema into Dify’s workflow graph schema.
Save + validate
Dify receives the workflow draft, validates it and prepares it for execution.
Execute
Dify invokes models, RAG, tools and APIs, then returns results and traces.
The adapter is our safety wall
Dify’s normal public Service API is designed mainly for running apps. To reproduce Studio-like management functionality, we need capabilities similar to the internal Console API used by Dify’s own frontend. We should hide that behind one adapter owned by us.
Good architecture
Fragile architecture
One dedicated environment per customer
Our intended commercial model is not “one Dify with many customer workspaces.” Instead, each company gets its own isolated deployment.
Our intended pattern
One customer = one isolated deployment. Their workflows, credentials, knowledge and runtime are separated at the infrastructure level.
Pattern to avoid without commercial authorization
One shared Dify = many customer workspaces. The current license defines a tenant as a workspace and restricts using the source to operate a multi-tenant environment unless authorized in writing.
What has already been built by the open-source community?
We did not find a polished, complete “replacement Dify Studio” that we can simply clone and ship. But we found projects that solve important pieces of the puzzle—especially programmatic control of Dify.
dify-mcp
Most important referenceExposes the Dify console surface programmatically through a large MCP/CLI tool registry. Its README currently documents 174 tools across 19 namespaces.
Why we care: it is a map of how to programmatically create apps, manipulate workflows, manage RAG, providers, plugins, runs, versions and more.
PSDify
Management automationA community project for programmatically managing Dify resources. Useful as another reference for automation around apps, knowledge and related workspace operations.
Why we care: it reinforces that Dify can be controlled beyond the public run API—but compatibility must be managed carefully.
coze2dify
Graph translation exampleConverts Coze workflows into Dify DSL/graphs. It has a frontend, backend, graph components and a conversion layer.
Why we care: it demonstrates the exact idea of translating a foreign workflow representation into a Dify-compatible graph.
Licensing and design guardrails
These are product-engineering guardrails, not legal advice. Before commercial launch, we should obtain written confirmation from Dify for our exact deployment model.
Current license explicitly allows
Commercial use including using Dify as a backend service for other applications or as an application-development platform.
Multi-tenant restriction
The current license says operating a multi-tenant environment using Dify source requires written authorization; a tenant is defined as a workspace.
Frontend / appearance
Dify’s frontend logo/copyright rules apply when using its frontend. The license also says the product’s interactive design is protected by an appearance patent.
✅ Our design goal
- Same category of capabilities
- Our own navigation and information architecture
- Our own visual node components
- Our own onboarding and terminology
- Our own workflow UX conventions
- Dedicated Dify deployment per customer
❌ Do not aim for
- Pixel-for-pixel copy of Dify
- Cloning every interaction exactly
- Taking Dify frontend and simply hiding branding
- One shared Dify with a workspace for every customer without authorization
- UI code tightly coupled to undocumented Dify endpoints everywhere
Recommended build roadmap
Do not rebuild every Dify screen on day one. Prove the adapter and the visual builder first.
Freeze one Dify version
Pick a known Dify version for development. Do not chase every upstream release while the product architecture is still changing.
Build the Dify adapter first
Implement app list/create, workflow draft read/write, validate, run and publish. This proves that our frontend can control Dify without depending on its frontend.
Build the simplest visual canvas
Start with a tiny node set: Start, LLM/Agent, Knowledge, HTTP Tool, Condition, Human Approval and Output.
Add knowledge + model configuration
Create our own screens for datasets, uploaded documents, model providers and credentials.
Add run history and debugging
Translate Dify traces into a clean visual execution timeline so business users can understand why a workflow failed.
Build customer deployment automation
One command or installer should provision the customer’s frontend, adapter, Dify, database, cache, storage and secrets.
What should our first MVP actually contain?
The first MVP should prove that a non-technical user can build and run a useful workflow without ever seeing Dify.
Dashboard
Agents, workflows, recent runs, templates.
Workflow Builder
Drag, connect, configure, test and publish.
Agent Setup
Instructions, model, tools, knowledge and variables.
Knowledge
Upload documents, see indexing status, test retrieval.
Connections
Model providers, APIs, credentials and MCP/tool endpoints.
Test Run
Run workflow from the builder with sample input.
Run Inspector
See every node, timing, output and error in simple language.
Publish
Activate a workflow/app after validation.
Technical structure we should aim for
A simple separation of responsibilities will keep the product maintainable.
| Layer | Suggested responsibility | Possible technology |
|---|---|---|
| Web UI | Dashboard, agent builder, workflow canvas, knowledge, settings | React / Next.js |
| Canvas | Nodes, edges, zoom, selection, graph editing | React Flow / XYFlow |
| Our API | Auth, validation, stable product endpoints | FastAPI / Node |
| Dify Adapter | Translate our objects into Dify objects; handle Dify upgrades | Dedicated service/module |
| Dify | Workflow/agent/RAG/tool execution | Self-hosted Dify |
| Customer data | Runtime DB, cache, files, vector storage | Dedicated per deployment |
| External systems | LLMs, APIs, email, CRM, ERP, MCP, databases | Provider/plugin/tool integrations |
Three risks the team must design for
1. Dify API changes
Some Studio-management behavior relies on console/internal surfaces, not only the stable public runtime API.
Mitigation: adapter layer + pin Dify versions + compatibility tests before upgrades.
2. Trying to build too much UI
Copying every Dify screen immediately will waste time and make the product complicated.
Mitigation: start with the 20% of features that unlock 80% of customer workflows.
3. License / design assumptions
Licensing terms and upstream behavior can change.
Mitigation: dedicated deployments, original UI, written confirmation from Dify before commercial scale.
The mental model to leave with
Own the UX
We differentiate through simplicity, workflow templates, enterprise integrations, deployment and user experience.
Reuse the engine
Dify saves us from rebuilding workflow execution, model orchestration, RAG and tool execution from scratch.
Protect the boundary
A clean adapter between our product and Dify lets us upgrade or even replace the underlying engine later.
Source notes
These links are included so engineering and legal can verify the assumptions directly.
Commercial backend use, multi-tenant restriction, frontend branding condition, appearance-patent notice.
Programmatic Dify console control; current README describes 174 tools across 19 namespaces.
Community automation/management project around Dify.
Coze → Dify graph/DSL conversion project with frontend/backend and graph-mapping examples.