How to Automate Dify Plugin Repackaging Using GitHub Actions: A Complete Guide

You can fully automate Dify plugin repackaging by using the plugin_repackaging.sh script inside a GitHub Actions workflow that downloads plugin dependencies, builds offline wheels, and repackages everything into a platform-specific .difypkg file.

The junjiem/dify-plugin-repackaging repository provides a production-ready solution to automate Dify plugin repackaging using GitHub Actions. This automation eliminates manual steps for creating offline-capable plugin packages, making it ideal for air-gapped environments or custom CI/CD pipelines.

Understanding the Dify Plugin Repackaging Workflow

The automation pipeline handles the complete lifecycle of converting a standard Dify plugin into an offline-ready package. When you trigger the GitHub Actions workflow, the system downloads the original plugin from the Dify Marketplace or GitHub releases, resolves all Python dependencies for the target platform, downloads those dependencies as wheels, and injects them back into the plugin structure.

The plugin_repackaging.sh script in the repository root orchestrates this process. It detects the operating system and architecture, constructs the appropriate platform tags (such as manylinux_2_17_x86_64 or manylinux_2_17_aarch64), and invokes the Dify binary CLI to produce the final repackaged artifact.

Core Components of the Automation Pipeline

The plugin_repackaging.sh Script

The plugin_repackaging.sh file serves as the core automation engine. It contains several key functions that handle different aspects of the repackaging process:

• market(): Downloads plugins directly from the Dify Marketplace API using the author, name, and version parameters.
• github(): Retrieves plugin packages from GitHub release assets.
• _local(): Processes locally stored plugin files.
• repackage(): Performs the actual unzipping, dependency resolution with pip download, wheel injection into requirements.txt, and final packaging using the Dify binary.
• install_unzip(): Ensures the unzip utility is available on RPM-based Linux runners.

The script accepts command-line flags -p for platform specification and -s for package suffix naming, enabling flexible targeting of different architectures.

The Dify Binary CLI

The repository includes pre-compiled Dify binary executables (such as dify-plugin-linux-amd64) that the script invokes to create the final .difypkg file. During the workflow execution, the script sets executable permissions with chmod 755 and uses this binary to package the modified plugin directory containing the offline wheels.

GitHub Actions Workflow Configuration

The .github/workflows/build.yml file defines the complete CI/CD automation. The workflow runs on workflow_dispatch events, accepting four key inputs:

1. plugin_author: The plugin author's identifier.
2. plugin_name: The plugin package name.
3. plugin_version: The specific version to repackage.
4. platform_arm: Boolean flag to target ARM64 architecture instead of x86_64.

The workflow executes several critical steps: resolving the platform string based on the platform_arm input, setting up Python 3.12, making the script executable, running the repackaging command with the appropriate flags, locating the output artifact, and uploading it using actions/upload-artifact.

How to Trigger Automated Repackaging

Manual Workflow Dispatch via GitHub UI

To manually automate Dify plugin repackaging using GitHub Actions, navigate to the repository's Actions tab, select the Build workflow, and click Run workflow. Fill in the required parameters:

• Plugin author: junjiem
• Plugin name: mcp_sse
• Plugin version: 0.0.1
• Platform arm: Check this box for ARM64 builds, leave unchecked for x86_64

The workflow will execute and produce an offline-ready plugin package within minutes.

Automated Triggering via REST API

For integration into external CI systems or automated pipelines, trigger the workflow using the GitHub REST API:

curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR_PERSONAL_ACCESS_TOKEN>" \
  https://api.github.com/repos/junjiem/dify-plugin-repackaging/actions/workflows/build.yml/dispatches \
  -d '{
    "ref":"main",
    "inputs":{
      "plugin_author":"junjiem",
      "plugin_name":"mcp_sse",
      "plugin_version":"0.0.1",
      "platform_arm":"false"
    }
  }'

This request initiates the automation pipeline, which will generate a file named junjiem-mcp_sse_0.0.1-offline.difypkg (or -offline-arm.difypkg for ARM builds) and make it available as a downloadable artifact.

Local Development and Testing

Before deploying to GitHub Actions, you can test the repackaging logic locally:

# Make the script executable

chmod +x ./plugin_repackaging.sh

# Repackage a Marketplace plugin for x86_64

./plugin_repackaging.sh \
  -p manylinux_2_17_x86_64 \
  -s offline \
  market \
  junjiem \
  mcp_sse \
  0.0.1

The script creates the final offline package in the repository root directory. For ARM64 targets, substitute the platform flag with -p manylinux_2_17_aarch64 and the suffix with -s offline-arm.

Key Files and Their Roles

File	Purpose	Direct Link
plugin_repackaging.sh	Main automation script handling download, dependency resolution, and repackaging.	View source
.github/workflows/build.yml	GitHub Actions workflow definition for CI/CD automation.	View source
dify-plugin-linux-amd64	Pre-compiled Dify CLI binary for Linux x86_64 used to package plugins.	View binary
README.md	Documentation covering usage, platform support, and configuration options.	View docs
Dockerfile	Container definition for running the repackaging process in isolated environments.	View source

Summary

• The junjiem/dify-plugin-repackaging repository provides a complete solution to automate Dify plugin repackaging using GitHub Actions.
• The plugin_repackaging.sh script handles the entire workflow: downloading plugins from the Marketplace or GitHub, resolving Python dependencies for specific platforms (manylinux_2_17_x86_64 or manylinux_2_17_aarch64), and repackaging with the Dify binary CLI.
• The .github/workflows/build.yml workflow enables one-click automation via workflow_dispatch, supporting both x86_64 and ARM64 architectures through input parameters.
• You can trigger the automation manually through the GitHub UI, via the REST API for CI integration, or run the script locally for development and testing.

Frequently Asked Questions

What is Dify plugin repackaging and why do I need it?

Dify plugin repackaging is the process of converting a standard Dify plugin package into an offline-capable .difypkg file that includes all Python dependencies as pre-downloaded wheels. You need this when deploying Dify in air-gapped environments, private networks without PyPI access, or when you want to ensure reproducible installations without external dependency resolution.

How does the GitHub Actions workflow handle different CPU architectures?

The workflow in .github/workflows/build.yml accepts a boolean input platform_arm that determines the target architecture. When set to false, the workflow sets PIP_PLATFORM=manylinux_2_17_x86_64 and PACKAGE_SUFFIX=offline for standard x86_64 builds. When set to true, it switches to manylinux_2_17_aarch64 and offline-arm, ensuring the pip download command fetches ARM-compatible wheels and the output filename reflects the architecture.

Can I use this automation for plugins hosted on GitHub instead of the Dify Marketplace?

Yes, the plugin_repackaging.sh script supports multiple source modes through its command structure. While the GitHub Actions workflow defaults to Marketplace downloads using the market command, the script also implements a github() function that can fetch plugins from GitHub releases. To use GitHub sources, you would modify the workflow step that executes the script, replacing market with github and adjusting the parameters to match the GitHub repository structure rather than Marketplace author/name format.

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