Dify plugin signature verification

Dify plugin signature verification and private plugins: when a self-hosted team needs it

Signature verification lets internal `.difypkg` packages install while unverified packages are refused. A team running Dify in its own infrastructure often wants custom tools or model integrations built in-house, and the temptation is to switch signature checks off so the package can be installed. This section explains why that trade is usually avoidable and what the team needs to decide before the first private plugin is built. Dify runs plugins through a plugin daemon in the Docker Compose stack, so the trust decision sits in that daemon's configuration, not in the console. The exact enforcement settings are documented in the Dify environment variable reference, and the reader should confirm them against the release in use before relying on any of them.

A private plugin is a package the organization builds, signs and distributes itself, so the team owns both the code and the signing key. Before building anything, decide who may hold the private key, where it is stored, and who approves a package before it is signed. Those decisions matter more than the install step, because a key that many engineers can use makes the signature check meaningful only on paper. Ask the platform team to confirm how the plugin daemon loads trusted public keys in the version you run, and whether it can be restricted to a defined set of sources. Write those answers down so the configuration can be reviewed later.

Plan the verification steps as part of the release process, not as a one-off task. Each internal plugin should go through the same path: build, review, sign, test on a staging instance, then install on production. Changing the trusted key set, or adding a new install source, should be a change that goes through the same review as any other security configuration. Dify releases arrive about monthly, so the team should also check the plugin daemon documentation with each upgrade, because enforcement defaults and key handling can change between versions. Confirm the current behavior with the release notes and the environment reference before each upgrade.

Which plugin source fits which team

This table compares the three plugin sources a Dify team can use: the official marketplace, private plugins signed with your organization's key, and unsigned local packages for development. Read each row against your own review capacity and risk tolerance. Configuration keys for verification and install sources must be taken from the environment reference for your target Dify release, not from memory.

Source	Trust basis	Who reviews the code	Operating effort and fit
Official marketplace plugins	Publisher identity and marketplace listing, verified through Dify's signing path for the release you run	The publisher, plus your own review if your policy requires it before install	Lowest internal effort. Fits general-purpose tools and model providers where the publisher is already trusted by your security team.
Private plugins signed with your organization's key	Your organization's private key held under your control, with the matching public key trusted by the plugin daemon	Your internal developers and reviewers, before signing	Recurring effort for key custody, signing each release and rotating trusted public keys. Fits internal tools that touch internal systems or customer data.
Unsigned local packages	None beyond the operator's decision to run them in a non-production instance	Usually the developer only, with no independent review step	Low setup effort but high risk. Fits development and testing on isolated instances only, and should not reach production.
Install source restrictions	Limits which sources the daemon will accept, so only approved origins can add code	Platform team, who owns the allowed source list	Recurring review of the allowlist. Confirm the exact keys with the environment reference for your target release before you rely on them.
Who should own the decision	Security and platform leads set the policy per source	Named owner for each plugin and its signing key	Write the policy before the first private plugin ships so exceptions are visible and traceable.

Setting up key pairs, signing and trusted keys in order

This sequence moves a private plugin from an unsigned build to a signed package that the Dify plugin daemon accepts only when its signature matches a trusted key. Each step ends with a check so the team knows the control works before it relies on it.

Confirm the signing tooling for your release
Before generating anything, the platform team checks the Dify plugin documentation for the exact release in use. Confirm which signing tool the release expects, which key format it accepts, and where the plugin daemon reads trusted public keys. Record these three answers in the change record, because the defaults can differ between releases. Done means the team can name the tool, the key format and the trusted key location from the release documentation, not from memory.
Generate the key pair in a controlled build environment
A named engineer generates the signing key pair on a dedicated build host or CI runner that is not the Dify host and has restricted access. Use the key type and format confirmed in the previous step. Label the key with its purpose and an owner, and record the key identifier. Done means a private key file and a matching public key file exist on the build host, and the fingerprints of both are written down for later comparison.
Move the private key outside the Dify host
Transfer the private key into a secrets store or hardware-backed vault that your organization already controls, then remove the local copy from the build host once the signing workflow can read it from that store. The Dify host should never hold the signing key, because a compromised host could then sign malicious plugins. Done means the private key is stored only in the approved vault, access is limited to named signing roles, and a test retrieval by an authorized role succeeds.
Sign the .difypkg file with the private key
Run the signing tool confirmed earlier against the packaged plugin, producing a signed .difypkg. Keep the unsigned original and the signed output as separate artifacts with distinct names, and store both with the build record. Done means the signed package exists, the signing command completed without errors, and the build log records the key identifier used, so anyone can trace which key signed which artifact.
Place the public key where the plugin daemon trusts it
Copy only the public key to the trusted key location named in the release documentation, using the mechanism that release describes for loading it. Do not copy any private material to the Dify host. Apply the change through the configuration path the upgrade and configuration guidance directs, and restart services only when that guidance says a restart is needed. Done means the public key file is in place, its fingerprint matches the one recorded at generation, and the plugin daemon logs show it loaded the key.
Enable signature enforcement
Turn on signature verification in the plugin daemon configuration, following the setting name and procedure in the documentation for your release. Confirm the setting is applied by checking the effective configuration rather than assuming the file edit took effect. Done means the enforcement setting is active, documented in the change record, and the owner who approved the change is named.
Test with three packages before approving the install path
Test a correctly signed package, which should install. Then test an unsigned package, which should be rejected. Finally, alter one byte or field of the signed package after signing and test it again, which should also be rejected. Record the result and the daemon log message for each case. Done means the three outcomes match expectations exactly, and any unexpected result stops the rollout until the cause is found and the test is repeated.
Document the trusted key and install process
Write down which public keys are trusted, who owns the private key, how keys are rotated, and which install sources are permitted for private plugins. Ask your team to confirm rotation steps against the Dify plugin documentation for the release in use before the first production install. Done means a named owner has reviewed the record and the team can repeat the full sequence from the written steps.

How signing differs across development, staging and production

Development is the only environment where unsigned local packages may be acceptable, and only on a separate instance that holds no production data, no production model credentials and no live customer documents. Keep it off the network paths production uses, so a test package cannot reach live workflows, knowledge bases or identity providers.

Key holder: the plugin author holds a development key pair. The private key stays on the author's workstation or in a personal secret store, and it is never committed to a repository.
Approver: no approval gate beyond the author. The developer decides what runs on the instance, and the instance should be clearly named as development in its console and hostname so no one mistakes it for production.
Evidence kept: a short record of the plugin name, version, source commit and the instance it was installed on. This is enough to trace a problem back to its origin.
Data rule: use synthetic data and throwaway model keys only, so nothing sensitive is exposed if a test package misbehaves.

Before anyone installs an unsigned package here, confirm that the development instance cannot reach production model endpoints, production knowledge sources or production identity systems.

Staging should mirror the production install path exactly: the same Dify version, signature enforcement switched on, the same trusted key set and the same install source restrictions. Its purpose is to catch a signing or trust failure before production does, so a passing staging run is only meaningful if the conditions match.

Key holder: a release engineer or security team member holds a staging signing key, separate from the development key. The trusted keys on staging should be the same set production will trust, or a clearly labelled subset of it.
Approver: the package owner requests promotion, and a second reviewer confirms that the signed artifact matches the reviewed source before it is installed.
Evidence kept: the hash of the signed .difypkg file, the identifier of the signing key, the install log showing that signature validation passed and the test results for the workflows the package touches.
Install path: install from the same internal source production will use, not from a file copied onto the server by hand.

Confirm that an unsigned package and a package signed with a development key are both rejected in staging, because a successful install only proves the trust model works if the rejection path was tested as well.

Security risks in private plugin signing and how to contain them

Signature enforcement only holds if the keys, the trusted key list and the install paths stay under control. The cards below cover where signing usually breaks down in a self-hosted Dify, and the control that contains each risk. Read them as one chain: a stolen key, an unreviewed trusted key or a loosened install path each lets an unapproved package reach the plugin daemon.

Private key exposure on a build host

The private key that signs your .difypkg files is the most valuable item in the chain. If it sits on a shared build server, in a repository or in a developer's home directory, anyone who reads it can produce packages that pass verification. Key custody means the key lives in a restricted store, only the signing job can use it, and access is logged. Ask who can read the key today and whether that list is written down.

Public key added without review

A trusted public key is the switch that decides which signatures the plugin daemon accepts. Adding one, or replacing one, changes what can run in your Dify without any code change. Require dual review for every change to the trusted key set, with one approver from the platform team and one from security. Confirm where the daemon reads its trusted keys and who can edit that file or configuration.

Enforcement turned off to get a package installed

When an install fails verification under deadline pressure, the fastest fix is to disable signature checking. That fix persists long after the release ships and quietly removes the control for every later plugin. Treat any change to the enforcement setting as a change record with an owner, a reason and an expiry, and check the setting in periodic reviews against the version you run.

Signed code is not the same as safe code

A valid signature proves who built a package and that it was not altered afterward. It does not prove the code is free of data exfiltration, unsafe calls or excessive permissions. Before signing, review the plugin's source, the tools and endpoints it calls and the credentials it requests. Keep the review record next to the signing record so the signature always points to a reviewed artifact.

Dependencies bundled inside the package

A .difypkg file carries its Python dependencies with it, so a signed package can include vulnerable or unmaintained libraries that no one reviewed individually. Pin dependency versions, generate a bill of materials for each build and scan it before signing. Confirm that rebuilds after a dependency update produce a new signed artifact that goes through the same review.

Install sources outside the approved channel

If the platform accepts plugins from any file upload or any URL, signature checks protect only the packages you remembered to sign. Restrict installation to the internal channel you control, and confirm which install paths your Dify version exposes to administrators. Review the list of allowed sources on a schedule so that a new path added by an upgrade does not go unnoticed.

What upgrades and key rotation change for installed plugins

Plan every Dify upgrade on the assumption that an installed private plugin may need re-testing. Dify minor releases arrive roughly monthly (1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026, according to the GitHub releases page), and each one can change the plugin daemon, the API that plugins call or the variables the stack expects. A package that installed cleanly on the previous version is not proof that it still loads, verifies and runs on the next one. Before each upgrade, take a backup, follow the upgrade guide for the target version, and compare your .env file with .env.example for new variables, as the Docker Compose guidance advises. Keep a staging copy of the stack and reinstall your signed packages there first.

Treat rotation of the plugin signing key as a planned change, not an emergency. Add the new public key to the daemon's trusted set while the old key is still accepted, re-sign each internal .difypkg with the new private key, then install and test the re-signed packages on staging and production. Only after every package you still use has a valid signature from the new key should you remove the old public key. Keep a record of which package versions were signed with which key and when, so that an audit or a rollback can show exactly which key vouched for an installed plugin. Confirm with your Dify version how the daemon handles multiple trusted keys before you rely on this sequence.

Rotating SECRET_KEY is a different operation with different effects. It signs session cookies and JWTs and encrypts OAuth credentials, so changing it logs out all users, and it is not a substitute for rotating plugin signing keys. The SECRET_KEY procedure, including its impact on stored OAuth credentials, is covered on its own page, and that page should be read before any change to it.

Limits to confirm before you rely on signed private plugins

Signed private plugins depend on settings, key management and install paths that vary by release and edition. The cards below list what to confirm in your own environment before you make signature enforcement a control you can point to. Check each item against the release notes and documentation for the exact version you run.

Enforcement settings and defaults

Confirm the exact environment variables that control whether the plugin daemon requires signed packages, and their default state in the release you deploy. Do not assume a default carries over from an earlier version or from a sample file. Test an unsigned package in a staging instance and confirm it is refused. Record the variable name, value and release in your change record so an auditor can see the state you verified.

Per-instance key management

Find out whether trusted public keys are managed per instance, through configuration, or through a store the console controls. Ask how a key is added, removed and revoked, and whether removal takes effect without a restart. If you run several plugin daemon instances, confirm how each one receives the same trusted key set and how you detect a daemon that is out of step. A mismatch can let one node accept a package that another rejects.

Community and Enterprise differences

Confirm which signing, key and access controls are available in the Community edition and which depend on Dify Enterprise. The public pricing page describes the Community edition as limited to a single workspace and the Enterprise edition as adding advanced security. Ask Dify which specific plugin governance features sit in each tier before you design around them, and get the answer in writing with your quote.

Install paths exposed in the console

List every route a user can take to install a plugin in your version of the console, including uploading a local package, installing from a URL, and installing from the marketplace. Some paths may bypass checks that others apply. Test each path with an unsigned and a signed package, and confirm that restricting one path does not leave another open. Remove or restrict paths that your policy does not allow.

Marketplace plugins and private signing

Confirm how plugins installed from the official marketplace are verified alongside your private keys. Ask whether enforcement applies to marketplace packages, whether your trusted keys can coexist with the vendor's verification, and what happens when a marketplace plugin updates. Do not treat marketplace trust as a substitute for your own review. Write down the answers for each release you run and recheck them on every upgrade.

Questions teams ask before signing their own Dify plugins

How much effort does it take to set up plugin signing in Dify?

Effort depends mostly on how many plugins you publish, how many Dify environments they must reach, and whether signing fits into a pipeline you already run. Setting up one key pair and signing a single plugin by hand is a small task. Repeating that for every plugin, every environment and every release is where the work grows, because each step needs a documented owner and a repeatable command. Ask any partner for a written breakdown that separates one-time setup (key generation, trust configuration, install-source rules) from recurring work (signing each release, rotating keys, reviewing new plugin versions).

What does the internal team need to provide for a private plugin project?

The internal team needs to supply a named owner for the plugin's purpose, access to the Dify instances where it will run, and a decision on who may hold signing keys. Engineers who understand the plugin's external calls, credentials and data handling must review the code, since the plugin daemon will run it. Someone must also own the build pipeline and the place where public keys are distributed. Without these people, signing becomes a formality that nobody can repeat after the first release.

Can our own team set up plugin signing without a partner?

Yes, a capable platform or security team can do this in-house, provided it has someone comfortable with key management, container-based build steps and the Dify plugin packaging format. The harder parts are usually not the signing command itself but the operating decisions around it: where private keys live, who can sign, how public keys reach each environment, and how a compromised key is replaced. Teams that already run a secrets manager and a release pipeline tend to find the work more contained. Teams without either often benefit from a written scope before they start.

What makes the effort go up for signed private plugins?

Four factors drive most of the effort: the number of plugins, the number of environments (development, staging and production each need correct trusted keys), the maturity of existing CI, and how well key management is already governed. A few plugins built by one team on a clean pipeline are straightforward. Many plugins across several teams, with keys stored in ad hoc locations and no rotation procedure, need more design before any build begins. Ask for the assumptions behind each factor to appear in the quote.

What does a fixed-scope engagement for private plugins cover?

A fixed-scope engagement is agreed in writing before work starts and lists the deliverables, the systems in scope and the timeline. For this topic, that typically means the key generation and storage design, signing steps for the agreed plugins, trusted public key configuration for the plugin daemon, install-source restrictions, and a handover of the procedure. Items outside that list, such as new plugin features or additional environments, would be added through a written change to scope. DeployOpen does not publish prices, so the quote follows from the agreed scope.

Does keeping signature enforcement on slow down releases?

It adds a defined step to each release, but the delay depends on how the step is built. A signing stage that runs automatically after tests adds little friction, while a manual process that waits on one person adds a queue. Enforcement itself does not change how the plugin runs. Confirm with your Dify version and your deployment method how enforcement is configured, because the exact settings can differ between releases and should be checked against the upgrade guide for your target version.

Who is responsible for key rotation after the first plugin ships?

Your organization owns key rotation after handover, and the procedure should name that owner in writing. The rotation plan needs to cover the signing key, the public keys trusted by each environment, and the process for re-signing and redistributing plugins that depend on the old key. Ask any partner to define these responsibilities, the expected recurring work and the support terms in the agreement. Ongoing support and upgrades can also be arranged as a retainer.

How DeployOpen scopes and delivers signed plugin work

DeployOpen plans and implements Dify plugin signing for self-hosted deployments in infrastructure you control. The work covers key generation, signing of private .difypkg files, trusted key distribution to the plugin daemon and install source restrictions, documented so your team can operate it after handover.

How we scope

Written scope lists the signing key ownership model, the private plugins in scope and the install sources allowed.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope names which environments receive signed plugins, such as staging before production, and who approves each release.

How we build

We generate the signing key pair and set custody rules for the private key outside the Dify runtime.
We sign each private .difypkg file, configure the plugin daemon with the trusted public keys and keep signature enforcement on.
We test that an unsigned or wrongly signed package is refused and that an approved package installs from the allowed source.

How we hand over

Deliverables include a runbook for signing, key rotation, adding a trusted key and revoking a compromised one.
Your team receives configuration records, the install source policy and a checklist for each plugin release.
Handover sessions walk your engineers through signing a new package and verifying it on a test instance.

How we support

Ongoing support, plugin upgrades and continuous testing are available as a retainer after handover.
Support can cover reviewing plugin releases before each Dify upgrade, since minor releases arrive roughly monthly.
Confirm with DeployOpen how key custody, incident response and retainer terms will be written into the agreement.

Dify plugin signature verification and private plugins