# How to Integrate with Dify's Built-in Plugin Package Command: A Complete Guide

> Integrate with Dify's built-in plugin package command using the junjiem/dify-plugin-repackaging script. Automate downloads and create offline-capable difypkg files easily.

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

---

**To integrate with Dify's built-in plugin package command, use the [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) script from the `junjiem/dify-plugin-repackaging` repository, which automates downloading dependencies and invokes the official `dify-plugin-*` binary to produce offline-capable `.difypkg` files.**

The `dify-plugin-repackaging` repository provides a Bash-based utility that bridges the gap between Dify's standard plugin distribution and air-gapped environments. By leveraging Dify's native packaging binary alongside custom dependency resolution logic, this tool enables developers to create self-contained plugin packages that include all necessary Python wheels for offline installation.

## Core Architecture and Components

Understanding the integration architecture is essential for customizing the repackaging workflow. The solution centers on a single entry-point script that coordinates multiple discrete operations before delegating final packaging to Dify's official tooling.

### The Main Orchestration Script

The **[`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh)** file serves as the CLI front-end and pipeline driver. Located at the repository root, this script parses command-line arguments, determines the plugin source (Marketplace, GitHub release, or local file), and executes the `repackage()` function to transform standard plugins into offline-ready packages.

### Platform-Specific Binaries

The integration relies on pre-compiled Dify binaries that perform the actual packaging operation. The script automatically detects the host operating system (`linux` or `darwin`) and CPU architecture (`amd64` or `arm64`) to select the correct binary:

- `dify-plugin-linux-amd64`
- `dify-plugin-darwin-arm64`

These binaries are invoked with the `plugin package` subcommand to generate the final `.difypkg` artifact after dependency preparation is complete.

### The Repackaging Pipeline

The `repackage()` function implements a four-stage pipeline:

1. **Unpack**: Extracts the original `.difypkg` using `unzip`
2. **Resolve**: Executes `pip download` to fetch platform-specific wheels into a `wheels/` directory
3. **Rewrite**: Modifies [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) to include `--no-index --find-links=./wheels/` for offline installation
4. **Package**: Calls `${CURR_DIR}/${CMD_NAME} plugin package …` to create the final offline package

## Command-Line Integration Methods

You can integrate the repackaging utility through three primary source pathways, each supporting optional flags for platform targeting and naming conventions.

### Integrating with Marketplace Plugins

To repackage a plugin from the Dify Marketplace, use the `market` subcommand followed by author, plugin name, and version:

```bash
./plugin_repackaging.sh market <author> <plugin_name> <version>

```

**Example:**

```bash
./plugin_repackaging.sh market langgenius agent 0.0.9

```

This command triggers the `market()` function, which uses `curl` to fetch the asset from the Dify Marketplace API before entering the standard repackaging pipeline.

### Integrating with GitHub Releases

For plugins distributed via GitHub releases, use the `github` subcommand:

```bash
./plugin_repackaging.sh github <repo> <release_tag> <asset_name.difypkg>

```

**Example:**

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

```

The `github()` function handles the download logic, retrieving the specified release asset before unpacking and repackaging.

### Local File Processing

To process an existing `.difypkg` file on your filesystem:

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

```

This bypasses remote fetching and immediately invokes `repackage()` on the local artifact.

## Advanced Integration Options

### Cross-Platform Targeting

When building packages for a different target platform than your host architecture, use the `-p` flag to specify the platform tag:

```bash
./plugin_repackaging.sh -p manylinux2014_x86_64 market junjiem mcp_sse 0.0.1

```

This translates to `pip download --platform manylinux2014_x86_64 --only-binary=:all:`, ensuring the downloaded wheels are compatible with the target environment even when building on incompatible architecture.

### Custom Output Naming

Override the default output filename suffix using the `-s` flag:

```bash
./plugin_repackaging.sh -s linux-amd64 market junjiem mcp_sse 0.0.1

```

The resulting artifact will be named `mcp_sse-0.0.1-linux-amd64.difypkg`, making version and platform identification explicit in CI/CD artifacts.

## Containerized and Automated Integration

### Docker-Based Workflow

For reproducible builds, the repository includes a `Dockerfile` that encapsulates the script and its dependencies (`unzip`, Python/pip):

```dockerfile
FROM alpine:3.18
COPY plugin_repackaging.sh /app/
COPY dify-plugin-linux-amd64 /app/
WORKDIR /app
CMD ["./plugin_repackaging.sh", "-p", "manylinux_2_17_x86_64", "market", "antv", "visualization", "0.1.7"]

```

Build and execute:

```bash
docker build -t dify-plugin-repackaging .
docker run --rm dify-plugin-repackaging

```

This approach ensures consistent dependency resolution regardless of the host environment.

### GitHub Actions Integration

The repository provides a pre-configured workflow in **[`.github/workflows/build.yml`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.github/workflows/build.yml)** that automates the repackaging process on push or tag events. The workflow executes [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) and uploads the resulting `.difypkg` file as a build artifact, enabling automated distribution of offline-ready plugins through your release pipeline.

## Summary

Integrating with Dify's built-in plugin package command requires coordinating dependency resolution with the official Dify binary:

- Use **[`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh)** as the primary interface, which supports Marketplace, GitHub, and local sources
- The script handles wheel downloading via `pip download` and modifies [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) for offline installation
- Final packaging is delegated to platform-specific binaries (`dify-plugin-linux-amd64` or `dify-plugin-darwin-arm64`)
- Cross-platform builds are supported via the `-p` flag for targeting different architectures
- Containerization via the provided `Dockerfile` ensures reproducible builds in CI/CD environments

## Frequently Asked Questions

### What is the role of the `dify-plugin-*` binary in the repackaging process?

The `dify-plugin-*` binary is the official Dify tooling that performs the final packaging operation. After the script downloads dependencies and rewrites [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt), it invokes `${CMD_NAME} plugin package` (where `CMD_NAME` is the platform-specific binary) to create the `.difypkg` file according to Dify's internal packaging specifications.

### How does the script handle Python dependencies for offline installation?

The `repackage()` function runs `pip download` to fetch all required wheels into a `wheels/` subdirectory, then uses OS-specific `sed` commands to prepend `--no-index --find-links=./wheels/` to the plugin's [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt). This ensures pip installs from local files rather than querying PyPI during installation.

### Can I build packages for different operating systems from my development machine?

Yes. Use the `-p` flag to specify a target platform (e.g., `manylinux2014_x86_64` or `win_amd64`) when invoking [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh). The script passes this to `pip download --platform`, which retrieves compatible wheels even when the host architecture differs from the target.

### Where can I find the automated workflow for CI/CD integration?

The file **[`.github/workflows/build.yml`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.github/workflows/build.yml)** contains the GitHub Actions workflow configuration. It demonstrates how to execute the repackaging script automatically on repository events and upload the resulting offline packages as downloadable artifacts.