dify-app-hub puts a user-facing chat layer in front of Dify apps

The product is a management and presentation layer over Dify applications

Dify App Hub describes itself in one dense sentence: a Dify application management platform built on the Dify API, offering a deeply optimised user-facing interface, supporting several Dify application types such as Chatflow and Workflow, adapted to rich AI output forms including deep thinking, chain of thought, chart rendering and file handling, and offering out of the box AI application solutions.

The order of that sentence matters. It comes after based on the Dify API, which places this project firmly on the client side. It is not a fork of Dify and not a competing workflow builder. Whatever authoring, prompt chaining and model routing happen, it happens in a Dify deployment that this project talks to.

The split shows up in what the repository contains and what it does not. There is no model provider integration in the dependency list, no vector store client, no node graph editor. Instead there are components for conversations, an Ant Design based interface, session storage through idb-keyval, authentication through next-auth, and a database layer for its own bookkeeping.

So there are two audiences. One is the end user who types into a chat window and expects a well rendered answer, with charts and files rather than raw text. The other is the operator who publishes a set of Dify apps behind one deployment and manages them there. The project is aimed at both, which is why the name says app hub rather than chat widget.

Rich model output is rendered, not escaped

The dependency list shows how much of the work is presentation. mermaid renders diagrams, echarts-for-react renders charts, katex handles mathematical notation, and dompurify sanitises HTML. Alongside them sit @ant-design/x and @ant-design/x-sdk for the conversational interface, radix-ui primitives for dialogs, accordions and collapsible panels, lucide-react and @heroicons/react for icons, and @svgdotjs/svg.js for vector drawing.

That combination is the answer to the chain of thought and deep thinking output forms mentioned in the description. A model that emits a reasoning trace, a diagram, a formula or a file reference produces markup that a plain text box would show as noise. The rendering libraries in package.json are what turn that output into something a user can read.

The sanitising library is the notable one from a security standpoint. dompurify at ^3.4.14 sits in the dependency list, which indicates that HTML from model output or from Dify responses is treated as untrusted and cleaned before insertion into the page. This matters because an app hub that renders arbitrary generated markup is a place where an injection payload has somewhere to land, and a front end that proxies third-party model output to a browser inherits that responsibility.

The same theme appears in the smaller dependencies. @fingerprintjs/fingerprintjs points at visitor identification, bcryptjs at password hashing, idb-keyval at browser side storage, i18next at translations, and nodemailer at email, so the project treats itself as a real application rather than a demo wrapper around a chat endpoint.

Next.js, Drizzle ORM and a MySQL connection hold the state

The application is a Next.js project written in TypeScript, with next at ^16.3.4 and React at ^19.2.3. The top-level entries include app/, components/, lib/, config/, db/, hooks/, packages/, services/, types/, and repository/, along with next.config.ts and a proxy.ts at the root.

Persistence goes through drizzle-orm, pinned at 1.0.0-rc.3, with drizzle.config.ts at the root and a db/ directory, and mysql2 as the driver. The project therefore keeps its own relational database for the things Dify does not store for it, such as which apps are exposed, who may use them, and what the operator configured.

There is also a pnpm workspace. pnpm-workspace.yaml and pnpm-lock.yaml sit at the root, and the package scripts include dev:docs and build:docs, both of which run through a pnpm filter for a package called dify-app-hub-docs. The documentation site is therefore built from the same repository and the same workspace rather than from a separate tree, which is why the Docker image and the docs can move together.

The quality tooling is consistent with that setup: vitest.config.ts and a __tests__/ directory for tests, eslint.config.mjs, oxlint and oxfmt configuration files, a .husky/ directory and .lintstagedrc.mjs for commit hooks, and an instrumentation.ts file at the root.

One compose file, one database variable, and port 5300

The README calls Docker Compose the most convenient way to start Dify App Hub, and the sequence is short. The compose file is downloaded from the repository, the environment variables are edited, and the service is started.

mkdir dify-app-hub && cd dify-app-hub
curl -O https://raw.githubusercontent.com/lexmin0412/dify-app-hub/main/docker-compose.yml
nano docker-compose.yml
docker compose up -d

The compose file is designed to stand alone, without cloning the source repository, and it declares a single service named app running the image lexmin0412/dify-app-hub:latest. It publishes port 5300 on the host, sets a restart policy of unless-stopped, and joins a bridge network called dify-app-hub-network.

Two environment variables matter, and both are placeholders you have to replace:

DATABASE_URL=mysql://username:password@host:port/database_name
NEXTAUTH_SECRET=your-secret-key-here

The README singles out DATABASE_URL as the one to change first, which makes sense because without a reachable MySQL database the application has nowhere to keep its own state. NEXTAUTH_SECRET is the session signing secret for next-auth and has the same character: leaving the shipped placeholder in place would make every deployment share the same secret.

Note that the compose file has no service for MySQL itself and no service for Dify. Both live outside this file, so a first run needs a Dify API to point at and a database to point to before the container is useful.

The container image is a two stage Node 22 build running standalone output

The Dockerfile builds in one stage and runs in another, both on node:22.21.1-alpine. The builder enables corepack, copies package.json, pnpm-lock.yaml, pnpm-workspace.yaml and .npmrc, installs with pnpm install --frozen-lockfile, and runs pnpm build. It then produces a pnpm deploy of the app into /deploy with the --prod flag and removes the standalone node_modules directory from the Next.js output.

The runner stage copies that deploy output, the Next.js standalone build, the static assets, the public directory, the db directory and drizzle.config.ts, then adds docker/entrypoint.sh as the entrypoint. The final command is node server.js, with NODE_ENV set to production, PORT set to 5300 and port 5300 exposed.

Two consequences follow. First, the Node version is pinned to a specific patch release, 22.21.1, so a rebuild months later produces a different base image than the one you tested. Second, the database schema lives inside the image as the db directory and drizzle.config.ts, which means migrations are applied by the entrypoint rather than by a separate job, and the drizzle-kit scripts in package.json are development-time commands.

The root Dockerfile is not the only build path. There is a docker-bake.hcl for multi target builds, docker-compose.dev.yml for local development, and a Dockerfile at the root that produces exactly what the published image runs.

Local development runs on port 5300 with Drizzle migrations and a seed script

The package scripts are the clearest description of the developer workflow. The dev script runs next dev with PORT set to 5300, which matches the port the container publishes, so a local server and a containerised one behave the same way. build runs next build, start runs next start.

Database work has its own group of scripts: db:generate runs drizzle-kit generate, db:migrate runs drizzle-kit migrate, db:studio opens drizzle-kit studio, and db:seed runs tsx db/seed.ts. That seed step matters for evaluating the project, because a management platform with an empty database has nothing to show you and the seed script is the documented way to get content in.

Testing uses vitest, with test running vitest run and test:watch running vitest interactively. Linting goes through next lint. The docs site has its own dev and build scripts filtered by pnpm.

The .env.template file at the root is the place where local configuration is declared, and .node-version records the expected Node version, which matches the 22.21.1 base image used in the Dockerfile. For running the project outside Docker, that template plus the drizzle scripts is the whole local setup, and the README points further deployment methods at the documentation site.

MIT licensed, version 0.8.1, and built on a release candidate ORM

The licence is MIT, which lets the project be used, modified and embedded in a product without copyleft obligations, a practical point for a front end that a company may want to rebrand and deploy under its own name.

On maintenance, the last push to the repository was on 2026-09-08 and the repository is not archived. The release history runs v0.8.1 on 2026-09-08, v0.8.0 on 2026-06-06, and v0.7.1 on 2026-01-26, and package.json carries version 0.8.1. The version is still below 1.0, so the public interface can be expected to change between minor releases.

The dependency choices carry their own upgrade cost. drizzle-orm is pinned to 1.0.0-rc.3, a release candidate rather than a stable major, and next sits at ^16.3.4 with React at ^19.2.3. A front end that proxies model output is also sensitive to changes in the Dify API it consumes, and the repository does not pin a Dify version anywhere visible in the documentation listed here.

The project also keeps the artefacts a growing codebase accumulates: a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, an .all-contributorsrc file with a contributors table in the README, a .cii-assessment.md file, and AGENTS.md plus a .agents/ directory for guidance to automated contributors.

Editorial conclusion

dify-app-hub fits a team that has already built workflows in Dify and now needs a polished, public-facing surface for end users, plus a place to manage several apps from one deployment. It does not fit a team that wants to run Dify itself, since it is a client of the Dify API rather than a replacement for it, and a team unwilling to host a Next.js service with a MySQL database. Verify three things before adopting: that your Dify deployment exposes the API this front end expects, that you can live with the version 0.8.1 feature set and the 1.0.0-rc.3 drizzle-orm dependency it ships with, and that the single Docker Compose service on port 5300 with DATABASE_URL and NEXTAUTH_SECRET as its two environment variables matches your deployment constraints.

Frequently asked questions

Official sources

1. lexmin0412/dify-app-hub on GitHub
2. License: MIT
3. Project website
4. README
5. Releases