Dify-Plus: a management centre bolted onto Dify for enterprise quotas and billing

The gap Dify-Plus fills: metering and admin on top of Dify

Dify ships as an LLM application platform. It does not ship with a per-user balance, an API key spending cap, or a cost report. Dify-Plus exists because its authors hit that gap inside their own company and later open-sourced the patches. The README states the project is Dify-Plus = management centre + Dify secondary development, and that the features were first used internally.

The audience is narrow and specific: teams already self-hosting Dify who need to answer "who spent what" and "who is allowed to keep calling the API". The README lists the added capabilities plainly. User quotas with a balance check on conversations, asynchronous quota calculation, a usage display in the top-left corner, and a personal monitoring page. Key-level quota settings with a balance check on application API calls. A cost report and key usage analysis in the admin centre. Web public page login authentication. Administrator sync of applications into the template centre.

That is the whole pitch. It is not a new platform and the README says so directly: the name Dify-Plus does not mean it is better than Dify, only that it adds some enterprise-scenario features. Treat it as a patch set with a control panel, not as a competing product.

Two codebases, one login: how the management centre connects to Dify

The architecture is two applications stitched together. The admin centre lives in the /admin directory and is built on gin-vue-admin. Dify itself stays in api/ and web/. The README describes four things the management centre does: JWT integration with Dify, user synchronisation, user quota modification, and cost reports.

The JWT integration is the load-bearing piece. Without a shared token, an admin logging into the gin-vue-admin panel would be a stranger to Dify, and quota edits would have no identity to attach to. With it, the admin centre can act on Dify users. The repository layout supports this reading: admin/, api/, web/, docker/, scripts/ and sdks/ sit side by side at the top level, so the fork keeps the upstream Dify tree and adds a sibling admin application rather than folding admin routes into Dify's API.

The quota logic is described as asynchronous. The README says there is an asynchronous calculation of user quota, which matters because counting tokens or calls inline on every request would put the accounting in the request path. The README does not document where that asynchronous job runs or how it is scheduled, so anyone operating this should expect to find that out from the code rather than the documentation.

For separating fork code from upstream code, the project uses a naming convention: comments, file names, method names and table names that belong to the secondary development carry the word extend. Searching that keyword is the documented way to see what was changed. It is a low-tech approach, but it makes rebasing against upstream Dify more tractable than a diff with no markers.

Installing Dify-Plus with docker-compose

The README does not contain installation steps. It points to a wiki page titled deployment detailed steps (docker-compose) and a second page for source deployment. Anything below is the upstream Dify development flow from the repository Makefile, which is what the fork inherits, not a Dify-Plus-specific installer. Check the wiki before running any of it.

The Makefile defines a dev-setup target that chains three steps. The first copies the middleware environment file and starts the backing services with Docker Compose:

make dev-setup

The underlying step for the middleware layer, if you want to run it alone, is this. It copies docker/middleware.env.example to docker/middleware.env and brings up the middleware stack under the project name dify-middlewares-dev:

cd docker && docker compose -f docker-compose.middleware.yaml --env-file middleware.env -p dify-middlewares-dev up -d

The web step copies web/.env.example to web/.env and installs front-end dependencies with pnpm:

cp -n web/.env.example web/.env && cd web && pnpm install

The API step copies api/.env.example to api/.env, syncs Python dependencies with uv, and runs the database migration:

cd api && uv sync --dev && uv run flask db upgrade

After dev-setup completes, the Makefile reports that the backend development environment is ready but the web and API processes are not started. The admin centre under /admin has its own configuration, and the README links to gin-vue-admin's server and web config pages for that rather than restating the keys. It also has a section for Dify-Plus-specific environment variables, and that section currently says to be filled in. That is a real documentation hole: if the fork adds variables, the README does not yet list them.

What the README leaves undocumented

The clearest limitation is documentation coverage. The environment variable section for Dify-Plus additions is empty apart from a placeholder. The README does not document how the asynchronous quota calculation is triggered, what happens to in-flight requests when a balance hits zero, or how to roll back a quota change. It does not document backup or restore for the admin database, and it does not state what happens to admin-centre data during an upgrade.

The licence is the second constraint, and it is not a small one. The README says the project is secondary development on top of Dify and must follow Dify's open source agreement, and the repository LICENSE is described as essentially Apache 2.0 with a few additional restrictions. The project also states explicitly that it does not touch the multi-tenant functionality or logo and other copyright information covered by the original project's licence, and that anyone needing those should contact Dify directly for authorisation. If multi-tenancy is what you need, this fork is not the answer and the README says so.

The third issue is version tracking. The README says the project will keep following both gin-vue-admin and Dify releases. That is a commitment to a moving target. The recent releases listed are 1.16.1-beta.2, v1.16.1-beta.1 and 1.16.0-beta.1, all marked beta and all dated 2026-07-20 and 2026-07-21, with the 1.16.0 note describing a merge of upstream Dify 1.16.0 marked pre-release. A fork that merges upstream pre-releases is shipping code that upstream itself has not declared stable. The README does not describe a stable release channel.

Finally, the repository's last push was on 2026-07-21. That is the most recent signal in the repository, and it is roughly two months before this article's publication. The project is not archived, but nothing in the repository shows activity after that date.

Dify-Plus against running Dify and building the metering yourself

The honest alternative is plain Dify plus your own accounting. Dify's own documentation covers self-hosted environment configuration, and the README links to it directly. If you run upstream Dify, you keep a clean upgrade path: pull a new release, apply migrations, done. You also avoid inheriting a fork's beta cadence and its merge of upstream pre-releases.

The difference in approach is where the quota logic lives. With Dify-Plus, the balance check is inside the Dify request path and the admin centre is a second application with a shared JWT. You get a user quota display, an API key quota setting, cost reports and key usage analysis out of the box, and you get them without writing the integration. Building the same thing yourself means intercepting API calls at a gateway, storing usage in your own database, and building your own admin UI. That is more work, but the boundary is yours and nothing breaks when Dify changes its internals.

The trade-off is upgrade surface. Dify-Plus has to rebase onto two upstreams, gin-vue-admin and Dify. The extend naming convention exists precisely because that rebase is a recurring cost. If your team cannot absorb a merge whenever upstream Dify ships, upstream Dify with a metering proxy is the lower-risk shape. If quota enforcement inside the platform is the requirement and you would rather not build it, the fork saves that work.

Maintenance and upgrade cost, and what the licence means in practice

Maintenance here is a two-upstream problem. The README commits to following gin-vue-admin and Dify versions, and the release history shows merges of Dify releases, including a 1.16.0 merge labelled pre-release. Each merge is work: fork-specific files carry the extend marker, and any upstream change touching the same files creates a conflict.

On the licence, the README is explicit that the project follows Dify's open source agreement and that the repository is under the Dify Open Source License, which it describes as essentially Apache 2.0 with a few additional restrictions. Two practical consequences follow from what the README states, and neither is legal advice. First, the additional restrictions are not itemised in the README, so read the LICENSE file itself before commercial deployment. Second, the project states it does not include the multi-tenant functionality or logo and other copyright information of the original project, and directs anyone needing those to contact Dify for authorisation. If your plan depends on multi-tenancy, the licence position is the blocker, not the code.

The README also asks that the project name not be read as a claim of superiority over Dify, and describes the work as a community secondary development. That framing is consistent with the licence section: this is a derivative work, and its obligations flow from the original.

Editorial conclusion

Adopt Dify-Plus if you self-host Dify and need per-user quotas, API key spend limits and cost reports without building them yourself, and if you are comfortable running a fork that tracks two upstream projects. Do not adopt it if you need multi-tenancy or Dify's logo and branding rights, which the README explicitly says this project does not cover. Before deploying, verify the licence terms against your own use, confirm which upstream Dify version your target release merges, and read the docker-compose deployment wiki page, since the README itself does not contain the install steps.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. YFGaia/dify-plus on GitHub