Self-hosting Dify

Where self-hosting wins

It is free, and commercial use is explicit

Two primary sources agree. The licence says Dify "may be utilized commercially, including as a backend service for other applications or as an application development platform for enterprises", and the Enterprise FAQ says the Community Edition "can be self-hosted for free on your own infrastructure, with access to the core platform features", and adds that no licence key is required. The pricing page describes Community as being for "open-source enthusiasts, individual developers, and non-commercial projects", which is positioning rather than a licence term. The accurate reading is that paid work on a single-tenant install is allowed.

One workspace is enough for most teams

The multi-tenant clause binds only when you run more than one separated area without written authorisation from Dify: "one tenant corresponds to one workspace." For a single organisation on a single workspace, both extra conditions are quiet, as long as the console keeps its logo. Note also that people are a Cloud meter rather than a licence term: on Cloud, 3 members cost $590 per workspace per year and 50 cost $1,590 per workspace per year, while the licence itself does not count heads.

Your data, your model keys, your vector database

Self-hosting removes the message-credit meter entirely, since model calls go to your own API keys. The pricing page lists Vector DB Customize as "Self Manage" for Community, which is a limitation and a freedom in the same row: nobody caps your knowledge storage at 50 MB, and nobody runs it for you either.

Where Cloud and Enterprise still win

The install is the first cost. Issue #33051, opened 2026-03-05, is titled "Self-hosted deployment is too complex" and reports that "Users must manually copy .env.example to .env and then edit 100+ variables", with "No automatic secret generation"; it was closed as not planned. Community also keeps app logs for 30 days against unlimited on Enterprise, lists support as "Github Community", and leaves high availability, LLM API load balancing and the knowledge pipeline templates on the paid side.

The second thing to understand is that the enterprise gate is mechanical, not a flag you can flip. There is no ee/ directory and no second licence file: Dify ships one LICENSE for the whole repository, plus a DEPLOYMENT_EDITION setting. The module api/services/openapi/license_gate.py documents itself as "Enterprise-edition only. Community and Cloud deployments skip the gate entirely" and raises a forbidden response with the reason license_required when the deployment edition is ENTERPRISE, and a decorator named enterprise_license_required guards console endpoints. The features themselves are not in the public tree at all: the modules under api/services/enterprise/ are HTTP clients for a closed companion service, one of them commented as speaking to "dify-enterprise's /inner/api/rbac/* endpoints". So SSO, role management and multiple workspaces are not switched off in the code you have; the code that implements them was never shipped to you.

Choosing between Community and Enterprise

The decision in four steps:

1. Count workspaces first. If the answer is more than one, stop reading the feature table: that is a licence condition, and the remedy is written authorisation from Dify rather than a configuration change.
2. Check the branding requirement. If what you ship must not carry the Dify logo in the console or the web app, that is both the second licence condition and the Enterprise row "WebApp Branding Customization".
3. Price the gap honestly. Enterprise has no published price, so compare it with what you would otherwise buy: Cloud Team at $1,590 per workspace per year for 50 members, or the equivalent row from another vendor.
4. Budget the install, not only the licence. Expect the environment-variable work described in issue #33051, plan and operate your own vector database, and remember that Community app logs keep 30 days.