mirror of
https://github.com/langgenius/dify-docs.git
synced 2026-07-22 12:25:45 -04:00
docs: subgroup walkthroughs, shorten titles, widget-ize publishing
Walkthroughs sidebar: split the 12-page flat list into Cheatsheet + 'By Plugin Type' subgroup (tool/oauth/model/agent-strategy/datasource/ trigger/endpoint) + 'Full Walkthroughs' subgroup (flomo/slack-bot/ md-exporter/multimodal). Shortened the worst sidebar offenders: - 'Build Tool Plugins for Multimodal Data Processing in Knowledge Pipelines' -> 'Multimodal Tool' - '10-Minute Guide to Building Dify Plugins' -> 'Flomo Tool (10-min)' - 'Dify Plugin Development Cheatsheet' -> 'Cheatsheet' - 'Develop A Slack Bot Plugin' -> 'Slack Bot' - 'Build a Markdown Exporter Plugin' -> 'Markdown Exporter' - 'Add OAuth Support to Your Tool Plugin' -> 'Tool OAuth' - 'Neko Cat Endpoint' -> 'Endpoint Plugin' Publishing pages: rewrite around Mintlify widgets and bake in the actual reviewer process from the pr-review-helper skill: - release-to-dify-marketplace.mdx: full rewrite with a Tabs-based pre-submission checklist, the exact 12-check reviewer table the automated workflow runs, a Steps submit flow, AccordionGroup FAQ, CardGroup related resources, and a PR-lifecycle table. - release-overview.mdx: replace prose with a CardGroup chooser and a comparison table (audience / review / install path / versioning / best for). - release-by-file.mdx: Steps for both packaging and installing, CardGroup for next-step distribution methods. - third-party-signature-verification.mdx: scenario CardGroup, three-Step generate/sign/verify flow, three-Step daemon-enable flow. - faq.mdx: add 'Why was my Marketplace PR rejected?' entry covering the most common automated-check failures from the skill. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
crazywoola
@@ -399,17 +399,27 @@
|
||||
"group": "Development Guides & Walkthroughs",
|
||||
"pages": [
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/cheatsheet",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/tool-oauth",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/creating-new-model-provider",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/datasource-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/trigger-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/endpoint",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/agent-strategy-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-flomo-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-a-slack-bot-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-md-exporter",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-multimodal-data-processing-tool"
|
||||
{
|
||||
"group": "By Plugin Type",
|
||||
"pages": [
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/tool-oauth",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/creating-new-model-provider",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/agent-strategy-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/datasource-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/trigger-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/endpoint"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Full Walkthroughs",
|
||||
"pages": [
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-flomo-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-a-slack-bot-plugin",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-md-exporter",
|
||||
"en/develop-plugin/dev-guides-and-walkthroughs/develop-multimodal-data-processing-tool"
|
||||
]
|
||||
}
|
||||
],
|
||||
"icon": "code"
|
||||
},
|
||||
|
||||
@@ -6,7 +6,7 @@ dimensions:
|
||||
level: beginner
|
||||
standard_title: Cheatsheet
|
||||
language: en
|
||||
title: Dify Plugin Development Cheatsheet
|
||||
title: Cheatsheet
|
||||
description: A comprehensive reference guide for Dify plugin development, including
|
||||
environment requirements, installation methods, development process, plugin categories
|
||||
and types, common code snippets, and solutions to common issues. Suitable for developers
|
||||
|
||||
@@ -4,9 +4,9 @@ dimensions:
|
||||
primary: reference
|
||||
detail: examples
|
||||
level: intermediate
|
||||
standard_title: Develop A Slack Bot Plugin
|
||||
standard_title: Slack Bot
|
||||
language: en
|
||||
title: Develop A Slack Bot Plugin
|
||||
title: Slack Bot
|
||||
description: This guide provides a complete walkthrough for developing a Slack Bot
|
||||
plugin, covering project initialization, configuration form editing, feature implementation,
|
||||
debugging, endpoint setup, verification, and packaging. You'll need the Dify plugin
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: 10-Minute Guide to Building Dify Plugins
|
||||
description: Learn how to build a functional Dify plugin that connects with Flomo note-taking service in just 10 minutes
|
||||
title: Flomo Tool (10-min)
|
||||
description: Build a functional Dify tool plugin that connects to the Flomo note-taking service end-to-end in about ten minutes
|
||||
language: en
|
||||
standard_title: 10-Minute Guide to Building Dify Plugins
|
||||
standard_title: Flomo Tool (10-min)
|
||||
---
|
||||
|
||||
## What you'll build
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Build a Markdown Exporter Plugin
|
||||
title: Markdown Exporter
|
||||
description: Learn how to create a plugin that exports conversations to different document formats
|
||||
language: en
|
||||
standard_title: Building a Markdown Exporter Plugin
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Build Tool Plugins for Multimodal Data Processing in Knowledge Pipelines
|
||||
title: Multimodal Tool
|
||||
description: Configure a tool plugin to emit images, audio, or video so the Knowledge Base node can embed multimodal outputs alongside text
|
||||
---
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ dimensions:
|
||||
level: intermediate
|
||||
standard_title: Endpoint
|
||||
language: en
|
||||
title: Neko Cat Endpoint
|
||||
title: Endpoint Plugin
|
||||
description: Authors Yeuoly, Allen. This document details the structure and implementation
|
||||
of Endpoints in Dify plugins, using the Neko Cat project as an example. It covers
|
||||
defining Endpoint groups, configuring interfaces, implementing the _invoke method,
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Add OAuth Support to Your Tool Plugin
|
||||
title: Tool OAuth
|
||||
description: Replace manual API-key entry with an OAuth authorization flow so users grant access to third-party services with one click
|
||||
---
|
||||
|
||||
|
||||
@@ -63,6 +63,19 @@ The plugin SDK refreshes tokens automatically when they expire, provided your pr
|
||||
|
||||
## Marketplace publishing
|
||||
|
||||
### Why was my Marketplace PR rejected by the automated check?
|
||||
|
||||
The reviewer runs a 12-check pre-flight on every PR. The most common failures:
|
||||
|
||||
- **`author` in `manifest.yaml` contains `langgenius` or `dify`** — reserved for first-party plugins; use your own GitHub handle.
|
||||
- **`dify_plugin` SDK pin is below `0.5.0`** — bump the pin in `requirements.txt`.
|
||||
- **`README.md` contains Chinese characters** — move translations to `readme/README_zh_Hans.md` (see [Multilingual README](/en/develop-plugin/features-and-specs/plugin-types/multilingual-readme)).
|
||||
- **PR title or body contains Chinese** — only the bilingual notice line is allowlisted; everything else must be English.
|
||||
- **Missing `PRIVACY.md` or `_assets/`** — both are required, and `PRIVACY.md` must be non-empty.
|
||||
- **Version is already published** — bump `version` in `manifest.yaml` before re-submitting.
|
||||
|
||||
The full list of checks lives in [Publish to Dify Marketplace](/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace#reviewer-checklist).
|
||||
|
||||
### How long does the Marketplace review take?
|
||||
|
||||
PRs to `langgenius/dify-plugins` are typically reviewed within a few business days. PRs that haven't seen reviewer activity in 14–30 days are marked stale; respond on the PR to reset that timer.
|
||||
|
||||
@@ -7,68 +7,86 @@ dimensions:
|
||||
standard_title: Release by File
|
||||
language: en
|
||||
title: Package as Local File and Share
|
||||
description: This document provides detailed steps on how to package a Dify plugin
|
||||
project as a local file and share it with others. It covers the preparation work
|
||||
before packaging a plugin, using the Dify plugin development tool to execute packaging
|
||||
commands, how to install the generated .difypkg file, and how to share plugin files
|
||||
with other users.
|
||||
description: Package a Dify plugin into a `.difypkg` file you can install directly or hand off to others — no marketplace, no GitHub release required
|
||||
---
|
||||
|
||||
After completing plugin development, you can package the plugin project as a local file and share it with others. After obtaining the plugin file, it can be installed into a Dify Workspace. If you haven't developed a plugin yet, you can refer to the [Plugin Development: Hello World Guide](/en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin).
|
||||
A `.difypkg` is the portable form of a Dify plugin. Once you have one, anyone can install it through the Plugins page by uploading the file. This is the right path for **private plugins**, **internal testing**, or **out-of-band distribution** to a small group.
|
||||
|
||||
* **Features**:
|
||||
* Not dependent on online platforms, **quick and flexible** way to share plugins.
|
||||
* Suitable for **private plugins** or **internal testing**.
|
||||
* **Publishing Process**:
|
||||
* Package the plugin project as a local file.
|
||||
* Upload the file on the Dify plugins page to install the plugin.
|
||||
For wider distribution, see the [Publishing Overview](/en/develop-plugin/publishing/marketplace-listing/release-overview).
|
||||
|
||||
This article will introduce how to package a plugin project as a local file and how to install a plugin using a local file.
|
||||
## Prerequisites
|
||||
|
||||
### Prerequisites
|
||||
- The [Dify CLI](/en/develop-plugin/getting-started/cli) installed. Run `dify version` to confirm.
|
||||
- A completed plugin project. If you haven't built one yet, start with the [Tool Plugin walkthrough](/en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin).
|
||||
- The plugin tested with [remote debugging](/en/develop-plugin/features-and-specs/plugin-types/remote-debug-a-plugin) before packaging.
|
||||
|
||||
* **Dify Plugin Development Tool**, for detailed instructions, please refer to [Initializing Development Tools](/en/develop-plugin/getting-started/cli).
|
||||
<Note>
|
||||
The `author` field in `manifest.yaml` and every `provider/*.yaml` must match your GitHub handle. Mismatches cause `plugin_unique_identifier is not valid` at install time. See [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) for the full manifest spec.
|
||||
</Note>
|
||||
|
||||
After configuration, enter the `dify version` command in the terminal to check if it outputs version information to confirm that the necessary development tools have been installed.
|
||||
## Package the plugin
|
||||
|
||||
### Package the Plugin
|
||||
<Steps>
|
||||
<Step title="Move above the project">
|
||||
Navigate to the directory **above** your plugin project (so the project is a subdirectory of the current working directory).
|
||||
</Step>
|
||||
<Step title="Run the packager">
|
||||
```bash
|
||||
dify plugin package ./your_plugin_project
|
||||
```
|
||||
|
||||
> Before packaging the plugin, please ensure that the `author` field in the plugin's `manifest.yaml` file and the `.yaml` file under the `/provider` path is consistent with your GitHub ID. For detailed information about the manifest file, please refer to [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications).
|
||||
|
||||
After completing the plugin project development, make sure you have completed the [remote debugging test](/en/develop-plugin/features-and-specs/plugin-types/remote-debug-a-plugin). Navigate to the directory above your plugin project and run the following plugin packaging command:
|
||||
|
||||
```bash
|
||||
dify plugin package ./your_plugin_project
|
||||
```
|
||||
|
||||
After running the command, a file with the `.difypkg` extension will be generated in the current path.
|
||||
The CLI produces a `your_plugin_project.difypkg` file in the current directory.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Frame>
|
||||
|
||||
|
||||
</Frame>
|
||||
|
||||
### Install the Plugin
|
||||
## Install from the file
|
||||
|
||||
Visit the Dify plugin management page, click **Install Plugin** in the upper right corner → **Via Local File** to install, or drag and drop the plugin file to a blank area of the page to install the plugin.
|
||||
<Steps>
|
||||
<Step title="Open the Plugins page">
|
||||
In Dify, click the **Plugins** icon in the top-right corner.
|
||||
</Step>
|
||||
<Step title="Choose Install Plugin > Via Local File">
|
||||
Or drag the `.difypkg` onto the empty area of the Plugins page.
|
||||
</Step>
|
||||
<Step title="Confirm the install">
|
||||
Review the permissions the plugin requests, then click **Install**.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Frame>
|
||||
|
||||
</Frame>
|
||||
|
||||
### Publish the Plugin
|
||||
<Warning>
|
||||
Self-hosted Dify enforces signature verification by default. Unsigned `.difypkg` files installed via Local File will be rejected unless you sign them or change the verification setting. See [Third-Party Signature Verification](/en/develop-plugin/publishing/standards/third-party-signature-verification).
|
||||
</Warning>
|
||||
|
||||
You can share the plugin file with others or upload it to the internet for others to download. If you want to share your plugin more widely, you can consider:
|
||||
## Share the file
|
||||
|
||||
1. [Publish to Individual GitHub Repository](/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo) - Share the plugin through GitHub
|
||||
2. [Publish to Dify Marketplace](/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace) - Publish the plugin on the official marketplace
|
||||
Hand the `.difypkg` file to your users directly — over email, internal file share, or any channel you control. They install it with the same flow above.
|
||||
|
||||
## Related Resources
|
||||
If you want broader distribution instead, consider:
|
||||
|
||||
- [Publishing Plugins](/en/develop-plugin/publishing/marketplace-listing/release-overview) - Learn about various publishing methods
|
||||
- [Initializing Development Tools](/en/develop-plugin/getting-started/cli) - Configure plugin development environment
|
||||
- [Remote Debugging Plugins](/en/develop-plugin/features-and-specs/plugin-types/remote-debug-a-plugin) - Learn plugin debugging methods
|
||||
- [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) - Define plugin metadata
|
||||
- [Plugin Development: Hello World Guide](/en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin) - Develop a plugin from scratch
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Publish on GitHub" icon="github" href="/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo">
|
||||
Attach the `.difypkg` to a GitHub release; users install via repo URL.
|
||||
</Card>
|
||||
<Card title="Submit to Marketplace" icon="store" href="/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace">
|
||||
Open a PR against `langgenius/dify-plugins` for the official catalog.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Related resources
|
||||
|
||||
- [Publishing Overview](/en/develop-plugin/publishing/marketplace-listing/release-overview)
|
||||
- [Dify CLI](/en/develop-plugin/getting-started/cli)
|
||||
- [Remote Debugging](/en/develop-plugin/features-and-specs/plugin-types/remote-debug-a-plugin)
|
||||
- [Third-Party Signature Verification](/en/develop-plugin/publishing/standards/third-party-signature-verification)
|
||||
- [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications)
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
@@ -79,4 +97,3 @@ It will be automatically generated by the script.
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/develop-plugin/publishing/marketplace-listing/release-by-file.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
|
||||
@@ -4,88 +4,66 @@ dimensions:
|
||||
primary: operational
|
||||
detail: deployment
|
||||
level: beginner
|
||||
standard_title: Release Overview
|
||||
standard_title: Publishing Overview
|
||||
language: en
|
||||
title: Publish Plugins
|
||||
description: This document introduces three ways to publish Dify plugins - official
|
||||
Marketplace, open-source GitHub repository, and local plugin file package. It details
|
||||
the characteristics, publishing process, and applicable scenarios for each method,
|
||||
and provides specific publishing recommendations to meet the needs of different
|
||||
developers.
|
||||
description: Three ways to distribute a Dify plugin — Marketplace, GitHub repository, or local file — and how to pick the right one
|
||||
---
|
||||
|
||||
### Publishing Methods
|
||||
Dify supports three ways to distribute a plugin. They differ in how much vetting happens up front and how broad an audience the plugin reaches.
|
||||
|
||||
To meet the publishing needs of different developers, Dify provides the following three plugin publishing methods. Before publishing, please ensure that you have completed the development and testing of your plugin, and have read [Basic Concepts of Plugin Development](/en/develop-plugin/getting-started/getting-started-dify-plugin) and [Plugin Developer Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct).
|
||||
Before publishing, finish development and testing, and read the [Plugin Development Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct).
|
||||
|
||||
#### **1. Marketplace**
|
||||
## Choose a method
|
||||
|
||||
**Introduction**: The official plugin marketplace provided by Dify, where users can browse, search, and install various plugins with one click.
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Marketplace" icon="store" href="/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace">
|
||||
Official catalog. Reviewed, trusted, one-click install for every Dify user.
|
||||
</Card>
|
||||
<Card title="GitHub Repository" icon="github" href="/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo">
|
||||
Self-hosted on GitHub. No review; users install via repo URL.
|
||||
</Card>
|
||||
<Card title="Local File" icon="file-zipper" href="/en/develop-plugin/publishing/marketplace-listing/release-by-file">
|
||||
A `.difypkg` file you hand off directly. Right for private or internal plugins.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
**Features**:
|
||||
## Compare
|
||||
|
||||
* Plugins are reviewed before going online, ensuring they are **safe and reliable**.
|
||||
* Can be directly installed in personal or team **Workspaces**.
|
||||
| | Marketplace | GitHub | Local File |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Audience** | Every Dify user | Anyone with the repo URL | People you give the file to |
|
||||
| **Review** | Yes — 12 automated checks + human review | None | None |
|
||||
| **Install path** | One click from Marketplace UI | Install from GitHub dialog | Upload via Plugins page |
|
||||
| **Versioning** | New PR per version, automated workflow available | GitHub releases with `.difypkg` asset | Repackage and redistribute |
|
||||
| **Best for** | Polished, broadly useful plugins | Open-source projects, internal tools shared by URL | Private plugins, internal testing, ad-hoc distribution |
|
||||
|
||||
**Publishing Process**:
|
||||
<Tip>
|
||||
Many developers ship to **GitHub first** for fast iteration, then submit to the **Marketplace** once the plugin is stable. The same `.difypkg` works for all three methods — only the distribution channel differs.
|
||||
</Tip>
|
||||
|
||||
* Submit the plugin project to the **Dify Marketplace** [code repository](https://github.com/langgenius/dify-plugins).
|
||||
* After official review, the plugin will be publicly available in the marketplace for other users to install and use.
|
||||
## Quick rules of thumb
|
||||
|
||||
For detailed instructions, please refer to:
|
||||
- **Want broad reach and review?** Use the **Marketplace**.
|
||||
- **Want full control over releases and versioning?** Use **GitHub**.
|
||||
- **Private or one-off use?** Use a **Local File**.
|
||||
|
||||
[Publish to Dify Marketplace](/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace)
|
||||
## Related resources
|
||||
|
||||
#### 2. **GitHub Repository**
|
||||
|
||||
**Introduction**: Open-source or host your plugin on **GitHub** for others to view, download, and install.
|
||||
|
||||
**Features**:
|
||||
|
||||
* Convenient for **version management** and **open-source sharing**.
|
||||
* Users can install directly via the plugin link, without platform review.
|
||||
|
||||
**Publishing Process**:
|
||||
|
||||
* Push the plugin code to a GitHub repository.
|
||||
* Share the repository link, users can integrate the plugin into their **Dify Workspace** through the link.
|
||||
|
||||
For detailed instructions, please refer to:
|
||||
|
||||
[Publish to Individual GitHub Repository](/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo)
|
||||
|
||||
#### 3. Plugin File Package (Local Installation)
|
||||
|
||||
**Introduction**: Package the plugin as a local file (such as `.difypkg` format) and share it for others to install.
|
||||
|
||||
**Features**:
|
||||
|
||||
* Not dependent on online platforms, **quick and flexible** way to share plugins.
|
||||
* Suitable for **private plugins** or **internal testing**.
|
||||
|
||||
**Publishing Process**:
|
||||
|
||||
* Package the plugin project as a local file.
|
||||
* Click **Upload Plugin** on the Dify plugins page and select the local file to install the plugin.
|
||||
|
||||
You can package your plugin project as a local file and share it with others. After uploading the file on the plugins page, you can install the plugin into your Dify Workspace.
|
||||
|
||||
For detailed instructions, please refer to:
|
||||
|
||||
[Package as Local File and Share](/en/develop-plugin/publishing/marketplace-listing/release-by-file)
|
||||
|
||||
### **Publishing Recommendations**
|
||||
|
||||
* **Want to promote your plugin** → **Recommended to use Marketplace**, ensuring plugin quality through official review and increasing exposure.
|
||||
* **Open-source sharing project** → **Recommended to use GitHub**, convenient for version management and community collaboration.
|
||||
* **Quick distribution or internal testing** → **Recommended to use plugin files**, simple and efficient way to install and share.
|
||||
|
||||
## Related Resources
|
||||
|
||||
- [Basic Concepts of Plugin Development](/en/develop-plugin/getting-started/getting-started-dify-plugin) - Comprehensive understanding of Dify plugin development
|
||||
- [Plugin Developer Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct) - Understand the standards for plugin submission
|
||||
- [Plugin Privacy Data Protection Guide](/en/develop-plugin/publishing/standards/privacy-protection-guidelines) - Understand the requirements for writing privacy policies
|
||||
- [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) - Understand the configuration of plugin manifest files
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Plugin Development Guidelines" icon="clipboard-check" href="/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct">
|
||||
Quality bar for Marketplace submissions.
|
||||
</Card>
|
||||
<Card title="Privacy Guidelines" icon="shield-halved" href="/en/develop-plugin/publishing/standards/privacy-protection-guidelines">
|
||||
`PRIVACY.md` and data-disclosure requirements.
|
||||
</Card>
|
||||
<Card title="General Specifications" icon="file-code" href="/en/develop-plugin/features-and-specs/plugin-types/general-specifications">
|
||||
Manifest fields every plugin must set.
|
||||
</Card>
|
||||
<Card title="Getting Started" icon="rocket" href="/en/develop-plugin/getting-started/getting-started-dify-plugin">
|
||||
New to plugins? Start here.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
@@ -96,4 +74,3 @@ It will be automatically generated by the script.
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/develop-plugin/publishing/marketplace-listing/release-overview.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
|
||||
@@ -7,94 +7,171 @@ dimensions:
|
||||
standard_title: Release to Dify Marketplace
|
||||
language: en
|
||||
title: Publish to Dify Marketplace
|
||||
description: This guide provides detailed instructions on the complete process of
|
||||
publishing plugins to the Dify Marketplace, including submitting PRs, the review
|
||||
process, post-release maintenance, and other key steps and considerations.
|
||||
description: Submit a plugin to the Dify Marketplace — pre-submission checklist, the 12 reviewer checks, the PR flow, and what happens after approval
|
||||
---
|
||||
|
||||
Dify Marketplace welcomes plugin submissions from partners and community developers. Your contributions will further enrich the possibilities of Dify plugins. This guide provides a clear publishing process and best practice recommendations to help your plugin get published smoothly and bring value to the community. If you haven't developed a plugin yet, you can refer to the [Plugin Development: Hello World Guide](/en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin).
|
||||
The Marketplace is the official catalog of community-built and partner-built Dify plugins. Submitting your plugin here puts it one click away from every Dify user.
|
||||
|
||||
Please follow these steps to submit your plugin Pull Request (PR) to the [GitHub repository](https://github.com/langgenius/dify-plugins) for review. After approval, your plugin will be officially launched on the Dify Marketplace.
|
||||
Plugins are published by opening a Pull Request against [`langgenius/dify-plugins`](https://github.com/langgenius/dify-plugins). A reviewer (and a set of automated checks) walks through the PR, and on approval the plugin goes live on [marketplace.dify.ai](https://marketplace.dify.ai/) automatically.
|
||||
|
||||
### Plugin Publishing Process
|
||||
If you have not built a plugin yet, start with the [Tool Plugin walkthrough](/en/develop-plugin/dev-guides-and-walkthroughs/tool-plugin).
|
||||
|
||||
Publishing a plugin to the Dify Marketplace involves the following steps:
|
||||
## Before you submit
|
||||
|
||||
1. Complete plugin development and testing according to the [Plugin Developer Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct);
|
||||
2. Write a privacy policy for the plugin according to the [Plugin Privacy Data Protection Guide](/en/develop-plugin/publishing/standards/privacy-protection-guidelines), and include the file path or URL of the privacy policy in the plugin [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications);
|
||||
3. Complete plugin packaging;
|
||||
4. Fork the [Dify Plugins](https://github.com/langgenius/dify-plugins) code repository;
|
||||
5. Create your personal or organization folder in the repository and upload the packaged `.difypkg` file to your folder;
|
||||
6. Submit a Pull Request (PR) following the PR Template format in GitHub and wait for review;
|
||||
7. After the review is approved, the plugin code will be merged into the Main branch, and the plugin will be automatically launched on the [Dify Marketplace](https://marketplace.dify.ai/).
|
||||
The Dify reviewer runs an automated 12-check pre-flight on every PR. Most rejections are mechanical — fixing them up front saves a review cycle.
|
||||
|
||||
Plugin submission, review, and publication flow chart:
|
||||
<Tabs>
|
||||
<Tab title="Project files">
|
||||
Every plugin directory must contain:
|
||||
|
||||
| File / Folder | Purpose |
|
||||
| :--- | :--- |
|
||||
| `manifest.yaml` | Plugin metadata (name, author, version, etc.) |
|
||||
| `README.md` | English-only description, setup, usage |
|
||||
| `PRIVACY.md` | Privacy policy — required, non-empty |
|
||||
| `_assets/` | Plugin icon and any other static assets |
|
||||
|
||||
See [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) for manifest fields and [Privacy Guidelines](/en/develop-plugin/publishing/standards/privacy-protection-guidelines) for the privacy policy.
|
||||
</Tab>
|
||||
<Tab title="Manifest rules">
|
||||
- **Author** in `manifest.yaml` must not contain `langgenius` or `dify` — those are reserved for first-party plugins. Use your own GitHub handle.
|
||||
- **Version** must be a new value — submitting an already-published version is rejected.
|
||||
- **Icon** must be an actual icon in `_assets/`, not a leftover template default.
|
||||
</Tab>
|
||||
<Tab title="Dependencies">
|
||||
- `pip install -r requirements.txt` must succeed cleanly.
|
||||
- The plugin SDK pin must be at least `dify_plugin>=0.5.0`.
|
||||
- The plugin must install and package without errors against the current daemon (the reviewer runs `test-plugin-install.py` and `upload-package.py --test`).
|
||||
</Tab>
|
||||
<Tab title="Language">
|
||||
- **PR title and body** must be in English. The bilingual notice line `【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）` is the only allowlisted exception.
|
||||
- **`README.md`** must contain no Chinese characters. Add translations as `readme/README_<lang>.md` instead — see [Multilingual README](/en/develop-plugin/features-and-specs/plugin-types/multilingual-readme).
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Reviewer checklist
|
||||
|
||||
These are the exact checks the reviewer runs, in order. Treat this as your pre-flight before opening the PR.
|
||||
|
||||
| # | Check | Common cause of failure |
|
||||
| :--- | :--- | :--- |
|
||||
| 1 | **Single `.difypkg`** | PR includes more than one packaged file, or none |
|
||||
| 2 | **PR language** | CJK characters in title or body outside the allowlisted notice |
|
||||
| 3 | **Project structure** | Missing `manifest.yaml`, `README.md`, `PRIVACY.md`, or `_assets/` |
|
||||
| 4 | **Manifest author** | Author contains `langgenius` or `dify` |
|
||||
| 5 | **Icon** | Default template icon left in place, or icon missing |
|
||||
| 6 | **Version** | This version is already on the Marketplace |
|
||||
| 7 | **README language** | Chinese characters in `README.md` (use `readme/README_zh_Hans.md` instead) |
|
||||
| 8 | **PRIVACY.md** | Missing or empty |
|
||||
| 9 | **Dependencies install** | `pip install -r requirements.txt` errors |
|
||||
| 10 | **SDK version** | `dify_plugin` pinned below `0.5.0` |
|
||||
| 11 | **Install test** | Plugin fails to install via the daemon |
|
||||
| 12 | **Packaging test** | Plugin fails to repackage cleanly |
|
||||
|
||||
A failing check stops the review and posts a status table with `❌ Fail` rows and required fixes; you address them and push again.
|
||||
|
||||
## Submit the PR
|
||||
|
||||
<Steps>
|
||||
<Step title="Read the Plugin Development Guidelines">
|
||||
Skim the [Plugin Development Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct). Reviewers use them to judge non-mechanical concerns: uniqueness, brand alignment, content quality, IP, and maintenance commitment.
|
||||
</Step>
|
||||
<Step title="Write your privacy policy">
|
||||
Create `PRIVACY.md` in the plugin root (or host it and put the URL in the manifest). Follow [Privacy Guidelines](/en/develop-plugin/publishing/standards/privacy-protection-guidelines) — declare what data the plugin and any third-party services it calls collect.
|
||||
</Step>
|
||||
<Step title="Package the plugin">
|
||||
From the directory above your plugin project:
|
||||
|
||||
```bash
|
||||
dify plugin package ./your_plugin_project
|
||||
```
|
||||
|
||||
This produces `your_plugin_project.difypkg`.
|
||||
</Step>
|
||||
<Step title="Fork and add your file">
|
||||
Fork [`langgenius/dify-plugins`](https://github.com/langgenius/dify-plugins). Create a folder at `<your-author-name>/<your-plugin-name>/` and drop the `.difypkg` inside.
|
||||
</Step>
|
||||
<Step title="Open the PR">
|
||||
Push to your fork, then open a PR against `main` using the repository's PR template. Title and body in English.
|
||||
</Step>
|
||||
<Step title="Respond to the review">
|
||||
The automated checks post first, then a human reviewer follows up. Address feedback by pushing new commits — the checks rerun on each push.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Frame>
|
||||
|
||||
</Frame>
|
||||
|
||||
> **Note**: The Contributor Agreement in the above diagram refers to the [Plugin Developer Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct).
|
||||
<Tip>
|
||||
The first review usually lands within a week. If a reviewer doesn't respond in that window, they'll leave a comment explaining the delay.
|
||||
</Tip>
|
||||
|
||||
### During Pull Request (PR) Review
|
||||
## After approval
|
||||
|
||||
Actively respond to reviewer questions and feedback:
|
||||
Once the PR is merged, the plugin appears on [marketplace.dify.ai](https://marketplace.dify.ai/) automatically — no extra step.
|
||||
|
||||
* PR comments unresolved within **14 days** will be marked as stale (can be reopened).
|
||||
* PR comments unresolved within **30 days** will be closed (cannot be reopened, a new PR needs to be created).
|
||||
You own the plugin from that point on:
|
||||
|
||||
### **After Pull Request (PR) Approval**
|
||||
- **Bug fixes and feature requests.** Triage issues from your users.
|
||||
- **Compatibility updates.** When Dify ships a breaking API change, the team publishes migration notes; you update the plugin. Dify engineers can help if needed.
|
||||
- **Versioning.** Bump `version` in `manifest.yaml`, repackage, open a new PR with the new `.difypkg`. The [Auto-publish PR workflow](/en/develop-plugin/publishing/marketplace-listing/plugin-auto-publish-pr) automates this from a GitHub Action.
|
||||
|
||||
**1. Ongoing Maintenance**
|
||||
<Warning>
|
||||
While the Marketplace is in public beta, avoid breaking changes to plugins already in use. Add new fields instead of renaming existing ones; deprecate before removing.
|
||||
</Warning>
|
||||
|
||||
* Address user-reported issues and feature requests.
|
||||
* Migrate plugins when significant API changes occur:
|
||||
* Dify will publish change notifications and migration instructions in advance.
|
||||
* Dify engineers can provide migration support.
|
||||
## PR lifecycle
|
||||
|
||||
**2. Restrictions during the Marketplace Public Beta Testing Phase**
|
||||
| Status | What it means | What to do |
|
||||
| :--- | :--- | :--- |
|
||||
| **Open, awaiting review** | Within the first ~7 days, no action needed | Wait |
|
||||
| **Changes requested** | A check failed, or the reviewer left feedback | Push fixes; checks rerun automatically |
|
||||
| **Stale (14 days idle)** | No response from you in two weeks | Reply on the PR to reset the timer; it can be reopened |
|
||||
| **Closed (30 days idle)** | Closed for inactivity | Open a fresh PR — the closed one can't be reopened |
|
||||
|
||||
* Avoid introducing breaking changes to existing plugins.
|
||||
## Frequently asked questions
|
||||
|
||||
### Review Process
|
||||
<AccordionGroup>
|
||||
<Accordion title="How do I know if my plugin is too similar to an existing one?">
|
||||
The Marketplace deduplicates by *function*, not by *integration*. A second Google-search plugin that only adds new translations is a duplicate. A Google-search plugin that adds batched queries, better error handling, or a meaningful new capability is fine — say so in the PR description.
|
||||
</Accordion>
|
||||
<Accordion title="My PR was marked stale or closed. What now?">
|
||||
**Stale** PRs (14 days idle) can be reopened — reply on the PR or push a fix to restart the clock. **Closed** PRs (30 days idle) cannot be reopened; fix the feedback and open a fresh PR with the same package.
|
||||
</Accordion>
|
||||
<Accordion title="Can I update plugins during the public beta?">
|
||||
Yes. Avoid breaking changes — add fields rather than rename, deprecate before removing.
|
||||
</Accordion>
|
||||
<Accordion title="Can I publish a paid plugin?">
|
||||
Not currently. The Marketplace accepts free plugins only; monetization policies will be announced separately.
|
||||
</Accordion>
|
||||
<Accordion title="The PR body needs both English and Chinese for our team — is that allowed?">
|
||||
No. Only the single allowlisted bilingual notice line is permitted in the PR title/body. Put internal multilingual notes elsewhere (commit messages, internal docs).
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
**1. Review Order**
|
||||
## Related resources
|
||||
|
||||
* PRs are processed on a **first-come, first-reviewed** basis. Review will begin within 1 week. If there is a delay, reviewers will notify the PR author via comments.
|
||||
|
||||
**2. Review Focus**
|
||||
|
||||
* Check if the plugin name, description, and setup instructions are clear and instructive.
|
||||
* Check if the plugin's [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) meets format standards and includes valid author contact information.
|
||||
|
||||
**3. Plugin Functionality and Relevance**
|
||||
|
||||
* Test plugins according to the [Plugin Development Guide](/en/develop-plugin/getting-started/getting-started-dify-plugin).
|
||||
* Ensure the plugin has a reasonable purpose in the Dify ecosystem.
|
||||
|
||||
[Dify.AI](https://dify.ai/) reserves the right to accept or reject plugin submissions.
|
||||
|
||||
### Frequently Asked Questions
|
||||
|
||||
1. **How to determine if a plugin is unique?**
|
||||
|
||||
Example: A Google search plugin that only adds multilingual versions should be considered an optimization of an existing plugin. However, if the plugin implements significant functional improvements (such as optimized batch processing or error handling), it can be submitted as a new plugin.
|
||||
|
||||
2. **What if my PR is marked as stale or closed?**
|
||||
|
||||
PRs marked as stale can be reopened after addressing feedback. Closed PRs (over 30 days) require creating a new PR.
|
||||
|
||||
3. **Can I update plugins during the Beta testing phase?**
|
||||
|
||||
Yes, but breaking changes should be avoided.
|
||||
|
||||
## Related Resources
|
||||
|
||||
- [Publishing Plugins](/en/develop-plugin/publishing/marketplace-listing/release-overview) - Learn about various publishing methods
|
||||
- [Plugin Developer Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct) - Plugin submission standards
|
||||
- [Plugin Privacy Data Protection Guide](/en/develop-plugin/publishing/standards/privacy-protection-guidelines) - Privacy policy writing requirements
|
||||
- [Package as Local File and Share](/en/develop-plugin/publishing/marketplace-listing/release-by-file) - Plugin packaging methods
|
||||
- [General Specifications](/en/develop-plugin/features-and-specs/plugin-types/general-specifications) - Define plugin metadata
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Publishing Overview" icon="signs-post" href="/en/develop-plugin/publishing/marketplace-listing/release-overview">
|
||||
Compare Marketplace, GitHub, and local-file distribution.
|
||||
</Card>
|
||||
<Card title="Plugin Development Guidelines" icon="clipboard-check" href="/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct">
|
||||
The full content and quality bar reviewers apply.
|
||||
</Card>
|
||||
<Card title="Privacy Guidelines" icon="shield-halved" href="/en/develop-plugin/publishing/standards/privacy-protection-guidelines">
|
||||
How to write a `PRIVACY.md` that passes review.
|
||||
</Card>
|
||||
<Card title="Auto-publish PR Workflow" icon="robot" href="/en/develop-plugin/publishing/marketplace-listing/plugin-auto-publish-pr">
|
||||
GitHub Action that packages and opens the PR for you on every push.
|
||||
</Card>
|
||||
<Card title="Multilingual README" icon="language" href="/en/develop-plugin/features-and-specs/plugin-types/multilingual-readme">
|
||||
Add `readme/README_<lang>.md` files for non-English users.
|
||||
</Card>
|
||||
<Card title="General Specifications" icon="file-code" href="/en/develop-plugin/features-and-specs/plugin-types/general-specifications">
|
||||
Manifest field reference.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
@@ -105,4 +182,3 @@ It will be automatically generated by the script.
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
|
||||
@@ -7,101 +7,122 @@ dimensions:
|
||||
standard_title: Third-Party Signature Verification
|
||||
language: en
|
||||
title: Sign Plugins for Third-Party Signature Verification
|
||||
description: This document describes how to enable and use the third-party signature verification feature in the Dify Community Edition, including key pair generation, plugin signing and verification, and environment configuration steps, enabling administrators to securely install plugins not available on the Dify Marketplace.
|
||||
description: Enable signed `.difypkg` installation in Dify Community Edition without disabling signature verification entirely — generate keys, sign packages, distribute the public key
|
||||
---
|
||||
|
||||
<Warning>This feature is available only in the Dify Community Edition. Third-party signature verification is not currently supported on Dify Cloud Edition.</Warning>
|
||||
<Warning>
|
||||
Third-party signature verification is a **Dify Community Edition** feature. Dify Cloud manages signatures centrally and does not expose these controls.
|
||||
</Warning>
|
||||
|
||||
Third-party signature verification allows Dify administrators to safely approve the installation of plugins not listed on the Dify Marketplace without completely disabling signature verification. This supports the following scenarios for example:
|
||||
Self-hosted Dify enforces signature verification by default. Third-party signature verification lets administrators safely install plugins that are not on the Marketplace without disabling verification entirely.
|
||||
|
||||
* Dify administrators can add a signature to a plugin sent by the developer once it has been approved.
|
||||
* Plugin developers can add a signature to their plugin and publish it along with the public key for Dify administrators who cannot disable signature verification.
|
||||
Two scenarios:
|
||||
|
||||
Both Dify administrators and plugin developers can add a signature to a plugin using a pre-generated key pair. Additionally, administrators can configure Dify to enforce signature verification using specific public keys during plugin installation.
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Admin signs an approved plugin" icon="user-shield">
|
||||
The admin reviews a `.difypkg` from a trusted developer and signs it with their own key before installing.
|
||||
</Card>
|
||||
<Card title="Developer ships a signed plugin" icon="key">
|
||||
The developer signs the `.difypkg` and publishes the matching public key. Admins who trust the developer add that public key to the verification list.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Generate a Key Pair for Signing and Verification
|
||||
The mechanics are the same in both cases: generate a key pair, sign with the private key, verify with the public key.
|
||||
|
||||
Generate a new key pair for adding and verifying the plugin's signature with the following command:
|
||||
## Generate a key pair
|
||||
|
||||
```bash
|
||||
dify signature generate -f your_key_pair
|
||||
```
|
||||
|
||||
After running this command, two files will be generated in the current directory:
|
||||
Two files appear in the current directory:
|
||||
|
||||
* **Private Key**: `your_key_pair.private.pem`
|
||||
* **Public Key**: `your_key_pair.public.pem`
|
||||
| File | Use |
|
||||
| :--- | :--- |
|
||||
| `your_key_pair.private.pem` | Sign plugins (keep secret) |
|
||||
| `your_key_pair.public.pem` | Verify signatures (share publicly) |
|
||||
|
||||
The private key is used to sign the plugin, and the public key is used to verify the plugin's signature.
|
||||
<Warning>
|
||||
Guard the private key. Anyone who has it can sign plugins that pass verification on installations trusting your public key.
|
||||
</Warning>
|
||||
|
||||
<Warning>Keep the private key secure. If it is compromised, an attacker could add a valid signature to any plugin, which would compromise Dify's security.</Warning>
|
||||
## Sign and verify a plugin
|
||||
|
||||
## Add a Signature to the Plugin and Verify It
|
||||
<Steps>
|
||||
<Step title="Sign the package">
|
||||
```bash
|
||||
dify signature sign your_plugin_project.difypkg -p your_key_pair.private.pem
|
||||
```
|
||||
|
||||
Add a signature to your plugin by running the following command. Note that you must specify the **plugin file to sign** and the **private key**:
|
||||
Produces `your_plugin_project.signed.difypkg` in the same directory.
|
||||
</Step>
|
||||
<Step title="Verify the signed package">
|
||||
```bash
|
||||
dify signature verify your_plugin_project.signed.difypkg -p your_key_pair.public.pem
|
||||
```
|
||||
|
||||
```bash
|
||||
dify signature sign your_plugin_project.difypkg -p your_key_pair.private.pem
|
||||
```
|
||||
Confirms the signature matches before you distribute or install.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
After executing the command, a new plugin file will be generated in the same directory with `signed` added to its original filename: `your_plugin_project.signed.difypkg`
|
||||
<Info>
|
||||
If you omit `-p`, `dify signature verify` checks against the Dify Marketplace public key. Any plugin not signed by Dify will fail verification in that mode.
|
||||
</Info>
|
||||
|
||||
You can verify that the plugin has been correctly signed using this command. Here, you need to specify the **signed plugin file** and the **public key**:
|
||||
## Enable verification on the daemon
|
||||
|
||||
```bash
|
||||
dify signature verify your_plugin_project.signed.difypkg -p your_key_pair.public.pem
|
||||
```
|
||||
Admins install signed plugins by giving the plugin daemon a list of trusted public keys.
|
||||
|
||||
<Info>If you omit the public key argument, verification will use the Dify Marketplace public key. In that case, signature verification will fail for any plugin file not downloaded from the Dify Marketplace.</Info>
|
||||
<Steps>
|
||||
<Step title="Place the public key">
|
||||
Put the `.public.pem` file somewhere the daemon container can reach it. For Docker Compose installs:
|
||||
|
||||
## Enable Third-Party Signature Verification
|
||||
```bash
|
||||
mkdir -p docker/volumes/plugin_daemon/public_keys
|
||||
cp your_key_pair.public.pem docker/volumes/plugin_daemon/public_keys/
|
||||
```
|
||||
</Step>
|
||||
<Step title="Configure the daemon environment">
|
||||
Set these variables on the `plugin_daemon` service:
|
||||
|
||||
Dify administrators can enforce signature verification using pre-approved public keys before installing a plugin.
|
||||
| Variable | Value |
|
||||
| :--- | :--- |
|
||||
| `FORCE_VERIFYING_SIGNATURE` | `true` |
|
||||
| `THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED` | `true` |
|
||||
| `THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS` | Comma-separated paths to public keys inside the container |
|
||||
|
||||
### Place the Public Key
|
||||
A `docker-compose.override.yaml` snippet:
|
||||
|
||||
Place the **public key** corresponding to the private key used for signing in a location that the plugin daemon can access.
|
||||
```yaml
|
||||
services:
|
||||
plugin_daemon:
|
||||
environment:
|
||||
FORCE_VERIFYING_SIGNATURE: true
|
||||
THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED: true
|
||||
THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/public_keys/your_key_pair.public.pem
|
||||
```
|
||||
|
||||
For example, create a `public_keys` directory under `docker/volumes/plugin_daemon` and copy the public key file there:
|
||||
<Note>
|
||||
`docker/volumes/plugin_daemon` mounts to `/app/storage` inside the container, so the path in `THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS` must use the in-container path.
|
||||
</Note>
|
||||
</Step>
|
||||
<Step title="Restart Dify">
|
||||
```bash
|
||||
cd docker
|
||||
docker compose down
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
```bash
|
||||
mkdir docker/volumes/plugin_daemon/public_keys
|
||||
cp your_key_pair.public.pem docker/volumes/plugin_daemon/public_keys
|
||||
```
|
||||
Verified installs are now enforced — signed `.difypkg` files matching the configured public keys install cleanly; unsigned or mismatched ones are rejected.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
### Environment Variable Configuration
|
||||
## Related resources
|
||||
|
||||
In the `plugin_daemon` container, configure the following environment variables:
|
||||
|
||||
* `THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED`
|
||||
* Enables third-party signature verification.
|
||||
* Set this to `true` to enable the feature.
|
||||
* `THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS`
|
||||
* Specifies the path(s) to the public key file(s) used for signature verification.
|
||||
* You can list multiple public key files separated by commas.
|
||||
|
||||
Below is an example of a Docker Compose override file (`docker-compose.override.yaml`) configuring these variables:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
plugin_daemon:
|
||||
environment:
|
||||
FORCE_VERIFYING_SIGNATURE: true
|
||||
THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED: true
|
||||
THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/public_keys/your_key_pair.public.pem
|
||||
```
|
||||
|
||||
<Info>Note that `docker/volumes/plugin_daemon` is mounted to `/app/storage` in the `plugin_daemon` container. Ensure that the path specified in `THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS` corresponds to the path inside the container.</Info>
|
||||
|
||||
To apply these changes, restart the Dify service:
|
||||
|
||||
```bash
|
||||
cd docker
|
||||
docker compose down
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
After restarting the service, the third-party signature verification feature will be enabled in the current Community Edition environment.
|
||||
- [Package as Local File and Share](/en/develop-plugin/publishing/marketplace-listing/release-by-file)
|
||||
- [Publish to Individual GitHub Repository](/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo)
|
||||
- [Plugin Development Guidelines](/en/develop-plugin/publishing/standards/contributor-covenant-code-of-conduct)
|
||||
- [Publishing FAQ](/en/develop-plugin/publishing/faq/faq)
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
@@ -112,4 +133,3 @@ It will be automatically generated by the script.
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/develop-plugin/publishing/standards/third-party-signature-verification.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user