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

To integrate with Dify's built-in plugin package command, use the 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 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 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:

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

Example:

./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:

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

Example:

./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:

./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:

./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:

./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):

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:

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 that automates the repackaging process on push or tag events. The workflow executes 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 as the primary interface, which supports Marketplace, GitHub, and local sources
• The script handles wheel downloading via pip download and modifies 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, 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. 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. 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}