# How to Download Dify Plugins from Marketplace vs GitHub: Key Differences Explained

> Understand Dify plugin download differences between Marketplace and GitHub. Learn about URL construction and parameters for seamless integration. Get clear insights now.

- Repository: [Junjie.M/dify-plugin-repackaging](https://github.com/junjiem/dify-plugin-repackaging)
- Tags: how-to-guide
- Published: 2026-03-05

---

**The only functional difference between downloading Dify plugins from the Marketplace versus GitHub lies in the URL construction and input parameters—Marketplace downloads use a REST API endpoint requiring `author`, `name`, and `version`, while GitHub downloads fetch release assets using `repo`, `release`, and `asset` patterns—before both paths converge on the identical repackaging logic in [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh).**

When working with the `junjiem/dify-plugin-repackaging` repository to enable offline plugin installation, you must choose between two distinct acquisition methods. The [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) utility handles both sources through separate entry functions that ultimately execute the same offline preparation pipeline, differing only in how they resolve and fetch the original `.difypkg` file.

## Entry Points and Parameter Structures

The script branches based on the first positional argument, invoking either the `market` or `github` function defined in [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh).

**Marketplace Download (`market` sub-command):**
- Defined at lines **28–52**
- Requires three parameters: `plugin_author`, `plugin_name`, `plugin_version`
- Constructs a REST API call to the official Dify Marketplace

**GitHub Download (`github` sub-command):**
- Defined at lines **54–82**
- Requires three parameters: `GitHub_repo`, `release_title`, `asset_name` (must include `.difypkg` suffix)
- Constructs a standard GitHub release asset URL

## URL Construction and API Patterns

### Marketplace REST API Endpoint (lines 28–52)

For Marketplace downloads, the script assembles URLs using the `MARKETPLACE_API_URL` environment variable (defaulting to `https://marketplace.dify.ai`). The function builds the endpoint path as `/api/v1/plugins/<author>/<name>/<version>/download` at lines **42–44**, then executes a `curl` command to fetch the package. Error handling at lines **46–49** validates the `curl` return code and aborts with a Marketplace-specific message if the request fails.

```bash
./plugin_repackaging.sh market junjiem mcp_sse 0.0.1

```

This resolves to `https://marketplace.dify.ai/api/v1/plugins/junjiem/mcp_sse/0.0.1/download` before triggering the repackaging workflow at line **51**.

### GitHub Release Asset URLs (lines 54–82)

For GitHub downloads, the script utilizes the `GITHUB_API_URL` base (default `https://github.com`). At lines **66–74**, it constructs the path `/<repo>/releases/download/<release>/<asset>`, prepending the base URL if not already present. Like the Marketplace path, it performs `curl` validation at lines **76–79** but emits GitHub-specific error messages, then proceeds to repackaging at line **81**.

```bash
./plugin_repackaging.sh github junjiem/dify-plugin-agent-mcp_sse 0.0.1 agent-mcp_sse.difypkg

```

This resolves to `https://github.com/junjiem/dify-plugin-agent-mcp_sse/releases/download/0.0.1/agent-mcp_sse.difypkg`.

## The Unified Repackaging Pipeline (lines 99–146)

Regardless of the source, both download methods invoke the `repackage` function at lines **99–146**. This function:

1. **Environment Detection**: Determines `OS_TYPE` and `ARCH_NAME` (lines **16–24**) to select the correct `dify-plugin-<os>-<arch>` binary
2. **Extraction**: Unpacks the downloaded `.difypkg` archive
3. **Dependency Resolution**: Runs `pip download` (line **113**) to fetch all Python wheels defined in [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt)
4. **Requirements Rewriting**: Injects `--no-index --find-links=./wheels/` into [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) at lines **118–124** to enable offline installation
5. **Package Rebuild**: Invokes the platform-specific `dify-plugin` binary at line **140** to generate a new offline-ready `.difypkg` file with updated ignore files

## Practical Usage Examples

Download from the official Dify Marketplace for the MCP SSE plugin:

```bash
./plugin_repackaging.sh market junjiem mcp_sse 0.0.1

# Generates: junjiem-mcp_sse_0.0.1-offline.difypkg

```

Download from a GitHub release asset:

```bash
./plugin_repackaging.sh github junjiem/dify-plugin-agent-mcp_sse 0.0.1 agent-mcp_sse.difypkg

# Generates: dify-plugin-agent-mcp_sse-0.0.1-offline.difypkg

```

Process a locally cached package without network access:

```bash
./plugin_repackaging.sh local ./db_query.difypkg

```

## Summary

- **Source-specific entry points**: The `market` function (lines 28–52) and `github` function (lines 54–82) handle distinct parameter schemas and URL constructions
- **API vs Release semantics**: Marketplace uses `/api/v1/plugins/<author>/<name>/<version>/download` while GitHub uses `/releases/download/<release>/<asset>`
- **Convergent processing**: Both paths call `repackage` (lines 99–146) to extract dependencies, download wheels via `pip`, and rebuild offline-capable packages
- **OS/Architecture awareness**: The script automatically selects the correct `dify-plugin` binary based on `OS_TYPE` and `ARCH_NAME` detected at lines 16–24
- **Error context**: Each download path provides source-specific `curl` failure messages while sharing identical validation logic

## Frequently Asked Questions

### Can I use the same repackaging logic for both Marketplace and GitHub sources?

Yes. According to the `junjiem/dify-plugin-repackaging` source code, both the `market` and `github` functions in [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) resolve to the same `repackage` routine at lines 99–146. The only difference is how the original `.difypkg` is obtained and the naming convention of the output file.

### Why does the GitHub method require the `.difypkg` suffix in the asset name?

The GitHub download logic at lines 66–74 constructs a direct URL to a release asset, and the script expects the asset parameter to explicitly include the `.difypkg` extension to ensure it fetches the correct binary package rather than source code archives or other release artifacts. This specificity prevents ambiguity when repositories contain multiple file types in a single release.

### How does the script handle different operating systems and architectures?

Before any download occurs, the script executes environment detection at lines 16–24, setting `OS_TYPE` and `ARCH_NAME` variables. When the `repackage` function rebuilds the package at line 140, it invokes the corresponding `dify-plugin-<os>-<arch>` binary, ensuring the repackaged plugin matches your deployment environment regardless of whether you sourced it from the Marketplace or GitHub.

### What happens if the curl download fails?

Both download paths implement `curl` return code checking immediately after the fetch operation. The Marketplace logic at lines 46–49 and GitHub logic at lines 76–79 verify the exit status; if non-zero, the script aborts with a source-specific error message indicating whether the Marketplace API or GitHub release URL was unreachable, without proceeding to the repackaging stage.