Self-hosted Dify enforces signature verification by default. Third-party signature verification lets administrators safely install plugins that are not on the Marketplace without disabling verification entirely. Two scenarios:Documentation Index
Fetch the complete documentation index at: https://docs.dify.ai/llms.txt
Use this file to discover all available pages before exploring further.
Admin signs an approved plugin
The admin reviews a
.difypkg from a trusted developer and signs it with their own key before installing.Developer ships a signed plugin
The developer signs the
.difypkg and publishes the matching public key. Admins who trust the developer add that public key to the verification list.Generate a key pair
| File | Use |
|---|---|
your_key_pair.private.pem | Sign plugins (keep secret) |
your_key_pair.public.pem | Verify signatures (share publicly) |
Sign and verify a plugin
If you omit
-p, dify signature verify checks against the Dify Marketplace public key. Any plugin not signed by Dify will fail verification in that mode.Enable verification on the daemon
Admins install signed plugins by giving the plugin daemon a list of trusted public keys.Place the public key
Put the
.public.pem file somewhere the daemon container can reach it. For Docker Compose installs:Configure the daemon environment
Set these variables on the
A
plugin_daemon service:| Variable | Value |
|---|---|
FORCE_VERIFYING_SIGNATURE | true |
THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED | true |
THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS | Comma-separated paths to public keys inside the container |
docker-compose.override.yaml snippet:docker/volumes/plugin_daemon mounts to /app/storage inside the container, so the path in THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS must use the in-container path.Related resources
- Package as Local File and Share
- Publish to Individual GitHub Repository
- Plugin Development Guidelines
- Publishing FAQ
Edit this page | Report an issue