dify-plugin-repackaging: turning a Dify plugin into a package your server will accept

The install gap this script fills on self hosted Dify

Dify plugins ship as packages built for one operating system and one CPU architecture, and the normal install route goes through the Marketplace, which serves the build that matches the platform you are already on. That breaks down in two common situations. A team that develops on a Mac and runs Dify on Linux amd64 has a package for the wrong machine. A team that needs a plugin which was never published, or that must be patched locally, has no Marketplace entry to point at.

junjiem/dify-plugin-repackaging addresses both. It is a shell script that takes a plugin source and produces a repackaged .difypkg for a target platform, so the result can be uploaded through the local package install path in the Dify admin console. The script also ships prebuilt helper binaries in the repository root for Darwin and Linux on both amd64 and arm64, named dify-plugin-darwin-amd64, dify-plugin-darwin-arm64, dify-plugin-linux-amd64 and dify-plugin-linux-arm64, which is what makes it work without a local build of the underlying plugin daemon tooling.

This is a narrow tool. It does one job, and the rest of this piece looks at exactly how that job is done, where the documentation and the shipped examples disagree, and what you have to change on the Dify side before any of it is useful.

Three input modes in plugin_repackaging.sh

The script exposes three subcommands, each taking a different description of where the plugin comes from.

The market mode pulls a plugin from the Dify Marketplace by author, name and version:

./plugin_repackaging.sh market langgenius agent 0.0.9

The github mode pulls a plugin from a GitHub repository and lets you name the output file:

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

The local mode takes an existing package on disk and repackages it, which is the path you want when you already have a .difypkg that needs a different architecture:

./plugin_repackaging.sh local ./db_query.difypkg

The three modes share one shape, which makes the script easy to drive from a CI job or a Makefile. Arguments are positional and version specific, so a plugin version that does not exist in the Marketplace or in the GitHub release list fails early rather than producing an empty package. Note that the github mode requires the version to be pinned, so tracking an upstream branch head is not something this interface supports.

The -p platform string decides which CPU the package targets

The one option that matters most is -p, which takes a pip platform string. Repacking for a machine other than the one you are sitting at is the entire point of the tool, and this flag is how you name the target.

The documentation describes the two common cases plainly: manylinux2014_x86_64 for plugins running on an x86_64/amd64 operating system, and manylinux2014_aarch64 for aarch64/arm64. Older manylinux tags encode a glibc baseline, and a plugin built against a newer baseline will not load on an older server, so picking the tag deliberately rather than copying whatever the example happens to use is worth the minute it takes.

Here the docs and the shipped examples drift apart. The Docker walkthrough overrides the command with manylinux_2_17_x86_64, and the Dockerfile in the repository root sets its default command to manylinux_2_28_aarch64 for the langgenius/openai_api_compatible plugin at version 0.0.59. Those are PEP 600 style tags, not the manylinux2014 tags the prose recommends. The interface accepts any pip platform string, so all three forms work, but the written guidance and the working examples do not agree, which means you should pick the tag from your target host rather than by copying either one.

Building and running it through Docker

The documented install path is a Docker build. The repository includes a Dockerfile based on python:3.12-slim that installs curl and unzip, copies the tree into /app, marks the script executable, and points its default command at the plugin_repackaging.sh script for aarch64 targets.

The build itself is a single command:

docker build -t dify-plugin-repackaging .

Running it mounts the current directory so the resulting package lands on your host:

docker run -v $(pwd):/app dify-plugin-repackaging

On Windows the README gives the equivalent form:

docker run -v %cd%:/app dify-plugin-repackaging

Because the container runs the default command, you override it by appending the script and its arguments:

docker run -v $(pwd):/app dify-plugin-repackaging ./plugin_repackaging.sh -p manylinux_2_17_x86_64 market antv visualization 0.1.7

One thing worth checking: the Dockerfile rewrites /etc/apt/sources.list to point at mirrors.ustc.edu.cn for the Debian bookworm suites, including non-free and non-free-firmware. In an environment where that mirror is unreachable, the build fails during apt-get update before any plugin work begins.

Dify refuses unsigned and oversized packages by default

Repackaging is only half the job. The Dify platform on the other end has its own gates, and the project notes name the three settings you have to change in your .env configuration file before a locally built package will install.

Setting FORCE_VERIFYING_SIGNATURE to false allows the platform to install plugins that are not listed in the Dify Marketplace. Setting PLUGIN_MAX_PACKAGE_SIZE to 524288000 raises the package ceiling to 500M. Setting NGINX_CLIENT_MAX_BODY_SIZE to 500M lets the Nginx layer accept uploads of that size.

The order matters, because the first change removes a security control rather than a format restriction. Signature verification is what stops a marketplace admin from installing an arbitrary package from an unknown author. A repackaged package is by definition not a Marketplace artifact, so turning verification off is the documented route, but it means every plugin on that instance now bypasses the check. If you only need one locally built plugin, treat this as an instance level decision rather than a per package one.

After that, the installation step itself is in the Dify plugin management page, where you choose Local Package File and select the .difypkg you produced. The uploaded file is the only thing that crosses from your build machine into the running platform.

Prerequisites that will break the script on a modern Linux host

The script assumes a specific toolchain, and the assumptions are stated clearly enough to check before you start.

The first is unzip. The script uses yum to install it, and the documentation notes that yum only exists on RPM based Linux systems such as Red Hat Enterprise Linux, CentOS, Fedora and Oracle Linux, and that newer distributions have replaced it with dnf. On Debian or Ubuntu based systems, where the Dockerfile itself lives, the install step quietly has nothing to run. The instructions are to install the unzip command in advance on other distributions, so on a non RPM host the container route is the smoother path.

The second is Python. The documented requirement is a Python version the same as the one in dify-plugin-daemon, which the README states is currently 3.12.x. The Dockerfile pins python:3.12-slim to match, and if your host Python drifts, the repackaged plugin can be built against a different interpreter than the one the daemon will run it under.

Supported operating systems are Linux on amd64 and aarch64, plus macOS on x86_64 and arm64. Anything else, including Windows outside Docker, is not covered.

A GitHub Actions route, no releases, and a recent last push

The second documented workflow avoids building the image yourself. You fork the repository, open the GitHub page of your fork, run the workflow, and download the resulting artifact. That path is aimed at operators who want a repackaged package produced by a hosted runner rather than a local container, and it moves the dependency installation into someone else's machine.

On maintenance, the repository is not archived and the last push was on 2026-09-09, so the script is recent in absolute terms. It has no GitHub releases, which means there is no versioned artifact to pin and no changelog to read; updates arrive only through the main branch. There is also no licence file among the top level entries, which are .github/, .gitignore, Dockerfile, README.md, the four platform helper binaries, images/ and plugin_repackaging.sh. Without an explicit licence grant, redistribution and modification rights are unclear, which matters if you plan to vendor the script into your own infrastructure pipeline rather than run it once.

The helper binaries are committed directly to the repository, so a pull of the project brings platform specific executables along with it. That is convenient for a one shot run and worth reviewing before you wire it into an automated pipeline.

Editorial conclusion

Adopt this script if you run self hosted Dify and need a plugin for a CPU architecture your build machine does not match, or need a plugin that never reached the Marketplace. Skip it if you install from the Marketplace on matching hardware, since the platform already ships that path. Before you rely on it, check that your host has unzip available outside RPM systems, that your Python matches the 3.12.x line used by dify-plugin-daemon, and that your Dify .env already permits unsigned local packages.

Frequently asked questions

Official sources

1. Issues
2. junjiem/dify-plugin-repackaging on GitHub
3. Project website
4. README