# dify-plus: an extend keyword, upstream Docker images, and a placeholder for its own env vars

> A fork of the Dify LLM application platform that adds per-user and per-key quota accounting plus an admin panel built on a different scaffolding framework. Its build file still points at the upstream project's container registry, and the documentation of its new environment variables is a placeholder.

**YFGaia/dify-plus** — Dify-Plus is an enterprise-grade enhanced version of Dify, integrating an admin center based on gin-vue-admin and optimized for enterprise use cases. Dify-Plus = admin center + a Dify fork. Note: this is a community fork that strictly follows Dify's original license and does not include the original project's multi-tenancy feature or logo/copyright assets; contact Dify officially for related licensing and support.

- Repository: https://github.com/YFGaia/dify-plus
- Stars: 2,251 · Forks: 448
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/yfgaia-dify-plus

## Apache 2.0 with added restrictions, and the multi-tenant feature left out

The licensing paragraph at the bottom of the page is the one to read carefully, because the obvious assumption is wrong. The project states it is available under the Dify Open Source License, and then describes that license as essentially Apache 2.0 with a few additional restrictions. That is not the Apache license, and it is why the platform's own license field for the repository resolves to no named license rather than to Apache 2.0. The repository description is equally specific about scope: this is a community secondary development that follows the upstream copyright terms, and it explicitly does not include the original project's multi-tenant functionality or its logo, with a pointer to the upstream project's official channels for anyone who needs those. So the feature that makes an enterprise deployment multi-tenant is the one thing this fork will not give you.

```text
This repository is available under the Dify Open Source License (LICENSE),
which is essentially Apache 2.0 with a few additional restrictions.
```

## The build file names the upstream organisation's registry

The root Makefile begins with three variables that most forks would have rewritten. The registry variable is set to the upstream project's organisation on the public container registry, not to anything belonging to this fork, and the two image variables built from it are named for the upstream web and API images. The version variable is set to a floating tag. Every target in the file then works on upstream layout: the frontend lives under the web directory and is installed with a JavaScript package manager, the API lives under the api directory and is synced with a Python tool, and the middleware comes from a compose file in the docker directory with its own example environment file. None of that is wrong for a fork that intends to stay close to upstream. What it does mean is that running a build here publishes under someone else's namespace unless you edit the variable first, and that is the kind of detail a readme should say and does not.

## Three languages in one repository, and the primary one is only the frontend

The repository is reported as a TypeScript project, and that is accurate for the largest directory: the upstream web frontend. But the other two halves are not TypeScript. The API target in the build file syncs Python dependencies with a Python package tool and then runs a database migration through Flask, so the server side of the platform is Python. And the management centre that this fork adds, which lives under its own directory, is built on a separate scaffolding framework whose server side is Go and whose frontend is Vue. So one repository carries a TypeScript frontend, a Python API and a Go admin backend, and the platform's language statistic reflects only the first. That matters when you are triaging issues, because a bug reported as a TypeScript problem may actually live in the Flask service, and a pull request that touches the admin centre has to satisfy a third toolchain's conventions.

## The extend keyword is the entire provenance mechanism

There is one versioning rule stated, and it is a good one. The project says it follows the versions of both the scaffolding framework and the upstream platform, and that to mark everything it changed on top, it adds the keyword extend to comments, to file names, to method names and to table names, so you can search for that one word and see the whole secondary development. That solves the review problem well: an auditor can grep one token and get an inventory of every forked line, including the database tables, which is where a fork usually hides its real changes. It also has a cost the project does not mention. Because the convention is applied to file names and table names, merging a newer upstream release is not a mechanical merge, and a reviewer who does not run that grep will read the fork's files as if they were upstream's. Two more entries at the root reinforce the point: a copy of the upstream readme kept under a distinct name, and a backup file with a tilde suffix left over from a merge.

## Quota accounting, not features, is what this fork adds

Thirteen changes are listed, and the majority of them are metering. The first group is user quota: a check on conversation balance, an asynchronous calculation of what a user has consumed, a quota indicator in the top left corner, and a personal monitoring page. The second is API key quota, applying a balance limit to an application's programmatic calls. Then come usage counters per application, and a change so the application centre lists things ordered by how often they have been used. The management centre adds user quota modification and a cost report, and the screenshot captions name the reporting surfaces: key usage analysis and monthly key quota spend. So the actual product here is a metering and billing layer bolted onto an application platform, which is exactly the kind of thing an enterprise deployment needs and exactly the kind of thing that requires you to understand how the upstream stores usage before you trust the numbers.

## One entry lifts a sandbox restriction on purpose

Two of the thirteen entries link out to their own wiki pages, and one of them deserves to be read before it is enabled rather than after. The entry is named sandbox-full and its stated purpose is to release the function restrictions on the code execution node. That is a deliberate removal of a limit the upstream platform places on what its code execution environment may do, shipped as a supported option in a fork aimed at enterprise use. Nothing on the readme explains which functions are restricted by default, what the restriction protects, or how to revert, because the details live on the linked wiki page. The other linked entry is a login integration for DingTalk, the enterprise messenger. The rest of the list is more mundane and mostly in the direction of tighter control: authentication on the public web page, a cookie that can be authenticated, hiding key display from non-administrators, stopping ordinary members from disabling a model, and not rendering the model provider tab for ordinary members at all.

## The cleanup target deletes four data directories by path

The development setup targets are careful in one specific way: each environment file is copied from its example with a no-clobber flag, so an existing local configuration is never overwritten, and the echo text says so when it skips. The cleanup target is where the care stops. It brings the middleware compose project down, and then it removes four named volume directories and the API storage directory with a bare recursive delete, naming them explicitly rather than asking the orchestration tool to remove volumes. Because the deletes are path-based, they run regardless of which project name or compose file the containers were started with, and they do not ask the container runtime anything first. That is convenient for a developer and unforgiving of a mistyped path, and it is the kind of target worth reading before wiring into a script.

```bash
@rm -rf docker/volumes/db
@rm -rf docker/volumes/redis
@rm -rf docker/volumes/plugin_daemon
@rm -rf docker/volumes/weaviate
@rm -rf api/storage
```

## Beta releases named after upstream versions, and merge debris at the root

The release history explains the version numbers. The three most recent releases are a 1.16.0 beta, whose title says it merges the official upstream 1.16.0 pre-release, followed by two 1.16.1 betas the next day, and they exist so that an upstream merge is a visible event rather than a silent diff. The tagging is not consistent, though: one of the three carries a leading v in its tag and the other two do not. All three landed within two days, and the last push to the default branch was on 2026-07-21, so nothing has been committed since, even though the readme promises to keep following both upstream projects. The root directory is a fair picture of what merging an active upstream leaves behind: the upstream readme kept under a new name, a backup file with a tilde suffix, an authors file, and four separate directories of assistant instruction files for three different tools plus an MCP configuration. The continuous integration file is also inherited from upstream's hosting, not this fork's.

## Conclusion

dify-plus is worth looking at if the specific thing you need is per-user and per-key quota accounting with a cost report on top of Dify, because that is a narrow, real gap the upstream does not fill and the implementation is documented feature by feature. Three things to decide. Read the licence file rather than assuming Apache 2.0, because the project describes its own terms as Apache 2.0 with additional restrictions and deliberately excludes upstream features and branding. Audit the sandbox-full option before you enable it, since its stated purpose is to lift function restrictions in the code execution node. And read the build file before you build, because its image names point at the upstream organisation's registry rather than your own.

## FAQ

### What is dify-plus?

It is a secondary development of the Dify application platform aimed at enterprise use, adding user and API key quota accounting plus a management centre built on the gin-vue-admin scaffolding. The readme is explicit that the name does not mean the project is better than Dify, only that it adds more enterprise-oriented changes.

### What licence does dify-plus use?

It follows the Dify Open Source License, which the readme describes as essentially Apache 2.0 with a few additional restrictions, and the platform's licence field resolves to no named license. The repository description says the fork excludes the upstream multi-tenant functionality and logo and directs those requests to the official channels.

### How can I tell which code in dify-plus is the secondary development?

The project adds the keyword extend to comments, file names, method names and table names in everything it changed on top of upstream, so searching for that one keyword produces an inventory of the fork, including its database tables.

### What does the dify-plus management centre do?

Four things are listed: JSON web tokens bridged with Dify, user sync, user quota modification, and cost reports. Its code lives under the admin directory, and its configuration is documented by the upstream scaffolding project's own server and web guides.

### How is dify-plus deployed?

The readme gives no commands, only wiki links for docker-compose and source deployment, plus a Dify environment variable reference and the upstream admin guides. Its own section on newly added environment variables contains a placeholder saying it is to be filled in, and one section on overall services has no content at all.

## Sources

- [Issues](https://github.com/YFGaia/dify-plus/issues)
- [README](https://github.com/YFGaia/dify-plus/blob/main/README.md)
- [Releases](https://github.com/YFGaia/dify-plus/releases)
- [YFGaia/dify-plus on GitHub](https://github.com/YFGaia/dify-plus)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yfgaia-dify-plus