How to Use Docker for the Dify Plugin Repackaging Script

You can run the Dify plugin repackaging script inside a Docker container by building the image from the provided Dockerfile and executing plugin_repackaging.sh with your chosen source command (market, github, or local).

The junjiem/dify-plugin-repackaging repository provides a containerized solution for creating offline Dify plugin packages. Using Docker for the Dify plugin repackaging script eliminates the need to install Python 3.12, curl, or unzip on your host system, ensuring a consistent and isolated build environment.

What the Docker Image Contains

The container defined in Dockerfile bundles all dependencies required to execute the repackaging workflow.

Core Components

• Base Environment: Python 3.12 with pip, plus curl and unzip utilities installed via APT.
• Working Directory: The entire repository is copied to /app, with plugin_repackaging.sh made executable.
• Compiled Binary: The Dify packaging binary (dify-plugin-linux-amd64 or dify-plugin-linux-arm64) is included to generate the final .difypkg file.
• Default Entry Point: The image defaults to running ./plugin_repackaging.sh without arguments, which displays usage information.

Building the Docker Image

Clone the repository and build the image locally. The build process configures a Chinese APT mirror for faster package installation and prepares the execution environment.

git clone https://github.com/junjiem/dify-plugin-repackaging.git
cd dify-plugin-repackaging
docker build -t dify-plugin-repackager .

Running the Repackaging Script in Docker

The plugin_repackaging.sh script supports three distinct source commands. Each command downloads or locates the plugin, fetches Python wheels for the target platform, and produces an offline-ready package.

Repackaging from the Dify Marketplace

Use the market command followed by the publisher name, plugin name, and version.

docker run --rm -v "$(pwd)":/app dify-plugin-repackager \
  ./plugin_repackaging.sh -p manylinux_2_17_x86_64 \
  market junjiem antv 0.1.7

Repackaging from GitHub Releases

Use the github command to fetch a release asset. Provide the repository slug, release tag, and asset filename.

docker run --rm -v "$(pwd)":/app dify-plugin-repackager \
  ./plugin_repackaging.sh -p manylinux_2_17_x86_64 \
  github junjiem/dify-plugin-tools-dbquery v0.0.2 db_query.difypkg

Repackaging a Local Plugin File

Use the local command when you already have a .difypkg file on your host machine. You must mount the host directory containing the file.

docker run --rm -v "$(pwd)":/app dify-plugin-repackager \
  ./plugin_repackaging.sh -p manylinux_2_17_x86_64 \
  local ./db_query.difypkg

Key Command-Line Flags

When invoking the script inside Docker, these flags control the repackaging behavior:

• -p <platform>: Specifies the Python wheel platform (e.g., manylinux_2_17_x86_64, manylinux2014_aarch64). This is passed to pip download with --platform and --only-binary=:all: to ensure compatible wheels are fetched.
• -s <suffix>: Customizes the output filename suffix. The default is offline, producing <plugin-name>-offline.difypkg.
• market <publisher> <plugin> <version>: Downloads the specified plugin from the Dify Marketplace API.
• github <repo> <tag> <asset>: Downloads a release asset from GitHub.
• local <path>: Processes a local .difypkg file already present in the container filesystem.

The Repackaging Workflow Inside the Container

When you execute the Docker run command, the container performs the following steps:

1. Source Acquisition: Depending on the command (market, github, or local), the script downloads or locates the plugin package.
2. Extraction: The .difypkg file is unzipped to reveal the plugin manifest and requirements.txt.
3. Wheel Download: The script invokes pip download with the specified platform flag to fetch all Python dependencies as binary wheels into a wheels/ directory.
4. Manifest Modification: The original requirements.txt is rewritten to point to the local wheels/ directory using relative paths.
5. Packaging: The compiled Dify binary (dify-plugin-linux-amd64 or dify-plugin-linux-arm64) is invoked to repackage the modified plugin directory into a new .difypkg file with the offline suffix.

The resulting file appears in the mounted host directory, ready for deployment in air-gapped environments.

Summary

• The junjiem/dify-plugin-repackaging repository provides a Dockerfile that encapsulates Python 3.12, system utilities, and the repackaging script.
• You can build the image with docker build -t dify-plugin-repackager . and run it without installing dependencies on your host.
• The script supports three input sources: Dify Marketplace (market), GitHub Releases (github), and local files (local).
• Use the -p flag to specify the target Python platform for wheel compatibility and the -v flag to mount a host directory for output retrieval.

Frequently Asked Questions

What is the Dify plugin repackaging script?

The plugin_repackaging.sh script is a Bash utility in the junjiem/dify-plugin-repackaging repository that automates the creation of offline-ready Dify plugin packages. It downloads plugin sources, fetches Python wheels for specific platforms, modifies requirements.txt to use local dependencies, and invokes the Dify binary to generate a .difypkg file that works without internet access.

Do I need to install Python on my host machine?

No. When you use Docker for the Dify plugin repackaging script, the container includes Python 3.12 and all necessary tools (curl, unzip, pip). You only need Docker installed on your host system to build and run the image.

How do I specify a different architecture like ARM64?

Use the -p flag with an appropriate platform tag when running the container. For ARM64 architectures, specify a platform like manylinux2014_aarch64 or manylinux_2_28_aarch64. The script passes this value to pip download with --platform and --only-binary=:all: to ensure the downloaded wheels match your target architecture.

Where does the offline package file appear after running the container?

The offline package appears in the directory you mount to /app inside the container using the -v flag. For example, if you run docker run --rm -v "$(pwd)":/app ..., the generated <plugin-name>-offline.difypkg file will be in your current working directory on the host immediately after the container exits.

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