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

> Automate Dify plugin repackaging with GitHub Actions. This guide shows how to leverage the plugin repackaging script to download dependencies, build wheels, and create platform-specific .difypkg files efficiently.

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

---

**You can fully automate Dify plugin repackaging by using the [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.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:

```bash
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:

```bash

# 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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) | Main automation script handling download, dependency resolution, and repackaging. | [View source](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) |
| [`.github/workflows/build.yml`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.github/workflows/build.yml) | GitHub Actions workflow definition for CI/CD automation. | [View source](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.github/workflows/build.yml) |
| `dify-plugin-linux-amd64` | Pre-compiled Dify CLI binary for Linux x86_64 used to package plugins. | [View binary](https://github.com/junjiem/dify-plugin-repackaging/blob/main/dify-plugin-linux-amd64) |
| [`README.md`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/README.md) | Documentation covering usage, platform support, and configuration options. | [View docs](https://github.com/junjiem/dify-plugin-repackaging/blob/main/README.md) |
| `Dockerfile` | Container definition for running the repackaging process in isolated environments. | [View source](https://github.com/junjiem/dify-plugin-repackaging/blob/main/Dockerfile) |

## Summary

- The **junjiem/dify-plugin-repackaging** repository provides a complete solution to automate Dify plugin repackaging using GitHub Actions.
- The **[`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/.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`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/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.