dify-plugins: the registry behind the Dify Marketplace

A directory per plugin, with the author names as the directory names

The top level listing of dify-plugins is a long list of directories that look like GitHub handles, among them ADWilkinson, Atomic-Mail, BrightData, ChuHaoJiQi, DennyHo0917, Fusic, LinkedIn, Telnyx, TencentCloud, actionbook and many more, alongside generic names such as ace-step, acedatacloud and FinancialAI. That naming is the design of the repository. Each organisation that publishes to the Dify Marketplace gets a directory of its own, and inside it a subdirectory per plugin.

This is a distribution arrangement, not a monorepo of shared code. Nothing here is imported by the Dify platform at build time, and there is no single artifact you can install. The repository exists so that plugins are reviewable, so that a marketplace listing has a source location, and so that a plugin can be packaged and distributed as a file.

The repository description says it contains all the plugins listed in the Dify Marketplace plus illustrated plugin examples, which points at the two audiences the repository serves. The marketplace listing is the operational side, where users find and install plugins, and the examples are the teaching side, where a plugin author can see what a working one looks like. The primary language of the repository is Python, and it is not archived with a last push on 2026-10-20, although it publishes no GitHub releases, which is consistent with a registry that is updated by committing new plugin directories.

The platform that consumes all this is Dify itself, an open source platform for developing LLM powered applications, where users create and test AI workflows, integrate models and tools, and work with RAG pipelines, agent capabilities and model management.

Five plugin types, and what each one is responsible for

The plugin taxonomy in the project documentation is the most useful part of the repository for anyone deciding how to extend a Dify application, because each type has a different contract.

Model plugins integrate AI models, including mainstream LLM providers and custom models, and they handle the configuration and the requests sent to the model API. This is the type that turns a new provider into something the workflow editor can offer as a model option.

Tool plugins are third-party services that can be invoked by Chatflow, Workflow or Agent applications, and they provide API backed capabilities for Dify applications. The distinguishing property is that the tool is called by the application rather than by the model reasoning loop directly, although in an agent the model may decide to call it.

Agent Strategy plugins define the reasoning and decision making logic inside an Agent node: the logic for tool selection, for invocation, and for handling the results the model returns. The documentation describes this as the internal reasoning logic of agent nodes, and it is a different kind of extension from a tool, because it changes how the agent thinks rather than what it can reach.

Extension plugins are the lightweight case. They only provide endpoint capabilities, and the stated purpose is fast expansion through HTTP services, which is the right fit for straightforward integrations that need basic API invocation and nothing more.

Bundles are collections of plugins, and the point of a bundle is to let a user install a curated set at once instead of adding them one by one.

Publishing means a package file, a fork and a pull request

The submission process is documented in enough detail to follow, and it starts with what a plugin has to contain. You develop and test the plugin according to the plugin development guidelines and this repository's own Plugin Submission Requirements, which live in docs/plugin-submission-requirements.md. You write a plugin privacy policy in line with Dify's privacy requirements and record the file path or a URL for that policy in the plugin's manifest. You include your contact information and the URL of your source repository in the plugin README.md.

Those three requirements are the ones that catch people out. The privacy policy is not optional decoration, and the manifest reference to it is what a reviewer checks. The contact details and the source repository URL in the README are what make the plugin attributable once it is installed in someone else's Dify instance.

The publishing steps that follow are mechanical. You package the plugin into a .difypkg file for distribution. You fork this repository. You create an organisation directory under the repository's main structure, and inside it a subdirectory named after your plugin, where you place the plugin source code and the packaged .difypkg. The README text is cut off at that point, so the pull request and review step that completes the process is not described in the file, and the plugin documentation at docs.dify.ai is the reference for the rest.

The wider documentation set is organised in the same way, with a getting started page, a page on choosing a plugin type, a quick start for agent strategy plugins and a quick start for extension plugins, plus pages for the privacy protection guidelines and the code of conduct for contributors.

Cloud installation, self-hosting and the difference in what you can install

There are two ways to run Dify, and the choice changes what this repository is for. Dify Cloud is the hosted offering, and the self-hosting route is documented with a docker-compose quick start. The documentation site, the Discord channel, the Reddit community, the X account and the LinkedIn page are the same for both.

The difference is in the plugin story. A self-hosted installation is a deployment you own, which means the plugin set is something you install and manage on your own instance, and it means the set of plugins you can use depends on the Dify version you deployed and on the plugins you chose to install. A hosted installation is a service whose marketplace is populated for you, where a plugin is one click rather than a package you fetch and register.

For a team writing a plugin, the practical difference shows up in testing. A plugin under development is exercised against a local or self-hosted instance, where you can restart it and read its logs, and where the plugin version you test is the version you built. The marketplace listing is the distribution step that comes after that, and it applies to both routes.

The enterprise inquiry link in the header of the project page is the third option, and it is worth noting only because it tells you where the commercial boundary sits relative to the self-hosted edition.

What a repository of community plugins means for trust and for licensing

The licensing position here needs to be stated plainly, because it is the one thing a reader of the directory listing might assume and should not. The repository has no detected licence, and the top level entries are directories, a README, a CONTRIBUTING.md, a .github directory, a .gitignore and an assets folder, with no LICENSE file in the listing. Since every plugin directory belongs to a different author, each of those subdirectories carries its own terms, and the absence of a repository-wide licence means you cannot assume a single set of terms covers the code in the directories you are looking at.

That is the practical risk of using this repository as a source of code. A plugin in here is someone else's integration, with their own maintenance status, their own dependencies and their own idea of what an API key should be stored in. A plugin that talks to a third-party service also inherits that service's data handling, and the privacy policy that the submission process asks for exists precisely because that is a concern the marketplace takes seriously. The submission requirements are a filter, not a guarantee.

The other structural limit is that the plugin contract itself is not defined here. The type definitions, the manifest format and the runtime expectations live in the Dify documentation, and the documentation carries its own quick start pages that are updated as the platform changes. A plugin that was written against an earlier version of the platform may not behave the same way on a newer one, and the repository does not version plugin packages against platform versions.

There is also no test harness in the repository. The listing shows the plugin directories, not a continuous integration configuration that builds and checks every one of them, so the quality of what you install depends on the reviewer who accepted it and on its author.

How to pick a plugin from a very long list

With dozens of organisation directories in the listing, the practical question is how to narrow it down, and the answer comes from the type taxonomy rather than from the repository itself. If you need a model you do not have, you are looking for a model plugin. If you need to call a service from a workflow, that is a tool plugin. If you want to change how an agent decides, that is an agent strategy, and it is the type most people do not know exists. If all you need is a plain HTTP call, an extension plugin is the smallest thing that will do the job, and it is the fastest to build.

Bundles are the shortcut when you do not want to choose: a curated set that installs in one action, which matters when a workflow depends on several plugins at once and you would otherwise be adding them one at a time.

The illustrated plugin examples in the repository exist for exactly this decision, since they show what a complete plugin of each type looks like before you commit to writing one. The Dify Marketplace itself is where you browse what has already been published, and the documentation pages for each plugin type are linked from the project README so you can read the guidance for the type you have chosen without leaving the page.

The one thing to keep in mind is that every directory in this listing is third-party code that will run inside your own Dify instance with access to whatever you have configured, including model API keys and the data your workflows carry. Read the README of the specific plugin you plan to install, check what it reaches out to, and treat the marketplace listing as a directory rather than as an endorsement.

Editorial conclusion

dify-plugins is the place to look if you are extending a Dify application with a model provider, a tool, an agent strategy or a simple HTTP endpoint, and the submission rules make it a reasonable reference for what a publishable plugin has to include, such as a privacy policy referenced from the manifest and a README with contact details and a source repository URL. It is the wrong repository to treat as a library to depend on, since the packages are individual community submissions rather than a published artifact with one licence, and it is the wrong place to look for a stable API, because the plugin contract is defined in the Dify documentation and can change under it. Before you build on any plugin in here, read its own README and licence, since each directory belongs to a different author, and check that the plugin you need is published for the Dify version you deploy.

Frequently asked questions

Official sources

1. Issues
2. langgenius/dify-plugins on GitHub
3. README