Why Dify plugin installation policy becomes a governance question at enterprise scale
When several teams build Dify apps and each workspace can install plugins, the installation policy stops being a developer convenience and becomes a governance decision. Plugins run code and call external systems, so every plugin a workspace installs can read data from the apps that use it, send requests to internal or external services, and shape the output that reaches users. Without a central policy, the set of code running in production is decided one workspace at a time, by whoever last clicked install. The decision you need to make is which plugin sources are acceptable, who may approve exceptions, and how an approved version reaches workspaces created later.
This question appears mainly on Dify Enterprise with multiple workspaces. The Dify pricing page lists the self-hosted Community edition as free and limited to a single workspace, while the self-hosted Enterprise edition adds multiple workspaces, SSO, advanced security and professional support. A single-workspace deployment has one approval point almost by default. Once you run several workspaces, you need an explicit rule that applies to all of them. Confirm with Dify whether the Enterprise console exposes a plugin installation policy setting, which roles can change it, and whether it can be applied to workspaces created after the policy is set. Do not assume these controls exist until the vendor or your own test environment confirms them.
Choosing allow-all, official and partner, or Marketplace-only plugin sources
This table compares five plugin source postures, from allowing any plugin to permitting no installs at all, by risk, fit, what each blocks and the review effort it creates. Read each row as a starting point for the policy you set, then confirm with Dify which tier names and controls exist in the version you run. The main takeaway is that the looser the source list, the more review work falls on your security team for every plugin a workspace wants.
| Posture | Risk profile | Suits | What it blocks | Review effort |
|---|---|---|---|---|
| Allow all | Highest. Any publisher's code can run with the network and credential access granted to the plugin. | Sandbox-heavy teams testing many tools in isolated, non-production workspaces | Little beyond platform defaults. Confirm what the console enforces. | Low up front, high later because each new plugin needs ad hoc triage after the fact |
| Official and partner | Moderate. Publishers are vetted by Dify or a named partner, but their code still runs inside your environment. | Teams that need broad integrations and want a defined list of publishers to trust | Unvetted third-party publishers and community packages | Moderate. Security reviews the publisher list and occasional new publishers, not each release |
| Marketplace only | Moderate to lower. Plugins come from the Marketplace listing, but listing does not guarantee your own review. | Fast-moving teams that accept Dify's listing process as a baseline | Plugins installed from local packages or outside sources | Moderate. Review the plugins in use and track updates from listed publishers |
| Internal packages only | Lower for public sources, but depends on your own build and signing process. | Regulated teams that need a reviewed, versioned catalog of approved plugins | Marketplace installs and unreviewed local uploads | High. Your team owns building, testing, signing and approving every version |
| No installs | Lowest for plugin code. Existing built-in capabilities and approved apps remain the only extension path. | Workspaces handling sensitive data where any new code path needs a formal change | All plugin installation | Lowest ongoing, but teams may request exceptions that add review load |
Installing one approved plugin version in every current and future workspace
Existing workspaces are the hardest part of the change because they already hold plugins installed by different people at different versions. Before you change anything, record what each workspace has installed, including the plugin identifier, the version and the apps that call each plugin. Illustrative example: a finance workspace runs one version of an internal tool plugin while a marketing workspace still runs an older build with different credential fields.
- Inventory first: list every workspace, installed plugin, version and dependent app. Confirm how your Enterprise edition exposes this view across all workspaces.
- Compare against the approved set: flag plugins that are not on the approved list and any version that differs from the approved build.
- Schedule changes with app owners: an app that calls a tool can fail when its plugin is removed or replaced, so agree a window with each owner.
- Test input and credential changes: a newer version may change tool parameters, credential fields or output shape, so run each affected app in a test workspace before the change.
Check that every workspace's inventory matches the approved list before you mark the change complete.
New workspaces are where policy drifts silently. A workspace created after approval starts with whatever its defaults allow, so the approved set must reach it before its first builder installs anything. Ask the vendor whether an approved plugin set can be applied automatically to workspaces created later, and what that propagation covers: installs, versions, installation permissions or only some of these.
- Confirm automated propagation: get the answer in writing for your Enterprise version, including whether it runs at creation time or only when someone triggers it.
- Gate creation manually if needed: if propagation is not automatic, make workspace creation a ticketed step with a checklist that includes the plugin check.
- Restrict who can install: confirm which roles can install plugins and which sources the installation policy allows, such as Marketplace only, official and partner, or all.
- Test each new workspace: create a test workspace after each policy change and compare its plugin list with the approved list.
Check the first-day state of a newly created workspace, not only the state of the workspaces you configured by hand.
A rollback is needed when an approved version misbehaves in production, for example through a broken tool schema, a credential handling defect or a failing model call. A planned rollback depends on two things being kept during the original approval: the prior approved build and a record of where each version was deployed. Without both, the reversal becomes an improvised search through workspaces.
- Keep the prior build on record: retain the last approved package and its identifier so it can be reinstalled without a new download from an unknown source.
- Identify affected workspaces: use the inventory to list every workspace and app running the faulty version.
- Protect dependent apps first: where a plugin is broken, decide whether to pause affected apps or move them to a fallback before changing the plugin.
- Verify the reversal: confirm the version in each workspace and run a smoke test on a representative app. Check whether the faulty version also changed configuration that needs reversing.
Record the rollback decision, the affected workspaces and the verification evidence in the change log.
Dify ships minor releases roughly monthly. The Dify releases on GitHub list 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. A list approved in July can be out of date by September, so the policy needs a fixed review rhythm tied to both platform releases and plugin updates.
- Set a standing review interval: agree how often the approved list is re-reviewed, and trigger an extra review when Dify or a plugin publishes a new version.
- Read release notes for plugin impact: note security changes, compatibility changes and any plugin daemon changes in each release before approving anything new.
- Approve specific versions: name the exact plugin version in each approval, so every new version needs its own decision.
- Time-limit exceptions: give each exception an expiry date so it lapses unless someone renews it with a reason.
Check at each review that the approved list, the deployed versions and the latest platform release notes still agree.
How to set up the policy across workspaces
This sequence moves Dify plugin installation from case-by-case choices in each workspace to one posture, one approved version set and one policy that covers current and future workspaces. It ends with recorded evidence that every workspace runs only what the security team approved.
Confirm Enterprise prerequisites before any change
The platform team confirms the deployment meets the Dify Enterprise resources checklist before any plugin work starts. The checklist calls for Kubernetes 1.24 or later and Helm 3.14 or later, along with PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Record the versions actually running in each cluster, and confirm with Dify that your release supports the workspace policy controls you plan to use. Done when the versions are written down and the platform owner signs off.
Inventory installed plugins in every workspace
Workspace administrators, supported by the platform team, list every plugin installed in each workspace. For each entry, record the plugin name, publisher, source, installed version and the apps or workflows that call it. Ask your Dify contact whether the admin console can export this list across all workspaces at once; if not, review each workspace separately. Include plugins that are installed but no longer used, since they still carry risk. Done when every workspace has a complete, dated list reviewed by its owner.
Classify each plugin source against the posture
Choose the posture first: allow all sources, official and partner plugins only, or Marketplace-only. Then sort each inventoried plugin into allowed, needs review or removed under that posture, noting whether it comes from a private package, a GitHub repository or the Marketplace. Plugins that the posture would block are a business decision, so record the owner and the workflow that depends on each one. Done when every plugin has exactly one classification and each blocked plugin has an owner and an agreed replacement or removal plan.
Approve specific plugin versions for use
The security team, with the application owners, approves a named version for each plugin that passes review. The approval record should state the source, the version, the review outcome, the reviewer and the plugin's declared permissions and network calls. Keep the approved set short and tie each entry to a business use, because the approved version becomes the one every workspace runs. Done when the approved list is signed off by security and each entry links to its review record.
Pin approved packages with a signed process
The platform team obtains or builds each approved plugin as a package, signs it and stores the signed artifact where the policy will reference it. Confirm with Dify how the Enterprise policy checks signatures and whether signature verification can stay enabled for production, because the policy is only as strong as that check. Private plugins follow the same path: build, sign, record the hash and then promote. Done when every approved version exists as a signed artifact, the signing key is controlled by the platform team, and a test install of an unsigned package is refused.
Set posture and approved versions on Enterprise
An Enterprise administrator applies the chosen posture and the approved version list at the organization level, so the policy covers existing workspaces and any workspace created later. Confirm in the admin documentation for your release where this setting lives and whether new workspaces inherit it automatically. Record the change in your change control system with the person who made it and the time it took effect. Done when the policy shows as active at the organization level and a newly created test workspace inherits it.
Test the policy in a staging workspace
Before production, a staging environment on the same Dify release runs the full policy. Testers attempt to install an unapproved plugin, install an approved version, install an approved plugin from a blocked source and check how an approved plugin behaves when a newer version is published. They also confirm that an app depending on a removed plugin fails in the way its owner expects. Done when every test case has a recorded result and each failure is fixed and retested in staging before any production change.
Roll out and verify each workspace
Apply the policy to production, then verify each workspace individually against the inventory from the second step. For every workspace, confirm that installed plugins match the approved set, that blocked plugins are removed or flagged and that the apps depending on them still run. Repeat the check when a new workspace is created and after each Dify upgrade, since upgrades can change plugin behavior. Done when each workspace has a dated verification record and the platform team has a standing check for new workspaces.
Security risks a plugin policy has to address
A plugin runs code inside your Dify deployment, so it can reach the same credentials, networks and workspaces as the platform itself. The cards below name the risk areas a policy must cover, and each one lists what to confirm in your own environment before you rely on a control.
Unverified third-party code
A plugin runs with access to whatever the platform hands it, which can include model provider credentials stored in a workspace. Under a policy, the question is which publishers are allowed at all. The allowlist decides who can install code, so confirm how your Dify version scopes installation rights per workspace and whether a plugin can read credentials configured for other tools.
Outbound calls to internal hosts
Plugins that call APIs make outbound requests, and the SSRF_PROXY setting routes those requests through a proxy that blocks internal and private IP ranges. A plugin that needs an internal system will fail until that host is reachable through the proxy. Confirm with your platform team which internal hosts are exempted, how the exemption is scoped, and whether a plugin can reach hosts you did not approve.
Secret rotation side effects
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so changing it after deployment logs out all users. Plugins that store OAuth credentials depend on that encryption. A policy should treat key rotation as a planned change with a maintenance window, and should confirm how stored plugin credentials behave after the key changes before the rotation is scheduled.
Signature checks on private packages
Private plugins are distributed as packages, and the policy has to say which packages production will accept. Keeping signature checks enabled in production means a modified or unsigned package should be rejected at install time. Confirm how your Dify release handles verification, who holds signing keys, and how a rejected package is reported to the team that owns it.
Audit evidence of approvals
A policy only protects you if you can show who approved each plugin and when. Record the approval decision, the version approved, the workspaces it applies to and the person who installed it. Confirm which of these events your Dify edition logs natively and which must be kept in a ticket or change record outside the platform.
Drift between workspaces
Workspaces created later can differ from the ones reviewed earlier, leaving a plugin version in one workspace that nobody approved. Drift is most likely when workspaces are created by different administrators or when a plugin is updated in one place only. Compare installed plugin names and versions across all workspaces on a fixed schedule, and check the result against the approved list.
Questions buyers ask about enterprise plugin policy
What does an enterprise plugin policy cost and what drives the price?
Dify does not publish a price for the self-hosted Enterprise edition. The pricing page describes it as custom priced and says it adds SSO, multiple workspaces, advanced security, a commercial license and professional support, so the plugin policy work itself is not a separate list item from Dify. DeployOpen's fee follows from a written scope, and that scope is driven by the number of workspaces, how many plugins are already installed, how many approval tiers you need, and whether the policy must be enforced through your identity and deployment tooling. Ask for a quote that separates one-time setup (inventory, policy design, initial approvals, verification) from recurring work (re-review after each release, new plugin requests, and retainer support if you want it).
How long does a plugin policy rollout take?
Duration depends mainly on how many workspaces exist, how many plugins are in use, and how quickly your security and business owners can decide which plugins are approved. Dify's Enterprise deployment can run on Kubernetes with multiple workspaces, so a larger estate needs more inventory and more sign-off rounds than a single workspace. Use the written scope to set milestones: inventory, policy decision, approval of the initial plugin set, rollout to existing workspaces, and a check that new workspaces inherit the policy. Ask for the timeline to name the dependencies on your side, such as approver availability and change windows.
What does our team need to provide before the work starts?
You need to supply three things: a workspace inventory, named owners for each workspace, and written approval rules. The inventory should list every workspace, its builders, the plugins currently installed and their versions, and any workspace that depends on a plugin that may be removed. Owners are the people who can accept or reject a plugin for their area. Approval rules define who may approve a plugin, what evidence they need (source, maintainer, permissions, network calls, data handling), and how exceptions are recorded. Without these, the policy cannot be applied consistently.
Can our internal team set up the plugin policy without a partner?
Often yes, if your platform team already runs Dify administration and your security team can make approval decisions. The work is mostly configuration, documentation and verification rather than custom code. A partner adds the most value when the estate is large, when several workspaces have drifted from one another, or when you need evidence that the policy holds across new workspaces. Check whether your team has time to maintain the approved list after each Dify minor release, which arrives roughly monthly according to the release history, and whether someone will own exceptions when a business team asks for a plugin that is not on the list.
How often do plugin approvals need to be reviewed?
Plan for a review after every Dify minor release and after any plugin version change, because the release history shows minor releases arriving roughly monthly. Dify 1.17.0 was released on August 25, 2026 and 1.17.1 on September 10, 2026, which means approvals tied to a version can go stale within weeks. Approve a specific version rather than a plugin name, and define a light review for patch updates and a full review for changes in permissions, network access or data handling. Ask your partner or internal team to write the review cadence into the policy so it does not depend on memory.
Does a new policy block plugins that already run in existing workspaces?
It can, depending on how you apply it. A policy decision on its own does not remove plugins from workspaces. Enforcement is a separate step, so the rollout plan should state for each existing workspace whether unapproved plugins are removed, disabled, or flagged for owner review. Removing a plugin can break workflows and agents that depend on it, so the inventory should record those dependencies first. Ask for a rollout that moves workspace by workspace, with a rollback path and an owner sign-off before each removal.
What should we confirm with Dify before committing to a policy design?
Confirm with Dify which plugin installation controls your Enterprise edition provides, how an approved version is pinned or enforced across current and future workspaces, and whether signature checks can be kept on in production. Also confirm how the Enterprise licence terms apply to your planned deployment, since the Dify Open Source License restricts operating a multi-tenant environment without written authorization. Read the Dify Enterprise SSO introduction for how workspace access is scoped, and confirm that the controls you rely on exist in the version you will run.
Limits to confirm in your environment before you commit
A plugin installation policy is only as strong as the controls your Dify version actually enforces. The cards below list the points to confirm with the vendor and in a test environment before you write the policy into a statement of work or an operating procedure.
Policy controls in your edition
Confirm which plugin policy settings your Dify Enterprise version offers, such as allow-all, official and partner, or Marketplace-only modes, and whether each mode can be set per organization. The public pricing page confirms that Enterprise adds SSO, multiple workspaces and advanced security, but it does not list plugin policy options, so ask for the admin documentation for your exact release. Record the control names and where they live in the console.
Enforcing one version on new workspaces
Ask whether a single approved plugin version can be pinned so that every workspace created later receives it automatically, without an administrator installing it by hand. Also ask whether a workspace owner can override the pinned version. Test this by creating a new workspace in a staging instance and checking which plugin and version appear. Do not assume this behavior until you have seen it work.
Installed plugins when a policy tightens
Find out what happens to plugins already installed in running workspaces when you move to a stricter policy. Confirm whether they keep running, get disabled, or are flagged for removal, and whether that behavior differs between the Marketplace and private packages. Agree on a notice period and a rollback path with the vendor before you change the policy on production workspaces.
Open Source License limits on multi-tenant use
The Dify Open Source License forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. If you run many workspaces on Community code, or plan to, have counsel confirm whether that use needs a commercial agreement. Get the answer in writing before you rely on the Community edition for a multi-workspace policy.
Support coverage for private plugins
Ask who supports a private plugin you build or commission: the vendor, DeployOpen, or your own team. Confirm whether vendor support covers plugins that are not from the Marketplace, how plugin daemon issues are triaged, and how security fixes to the plugin SDK reach your private packages. Put the answers into the support section of the contract so that gaps are visible before an incident.
Keeping the approved plugin list current after each Dify release
Every Dify upgrade reopens the plugin decision, because an approved plugin version was tested against a specific platform release. Before any upgrade, take a backup, then read the upgrade guide for the target version on the GitHub Releases page and the release notes for every version you will cross. The Docker Compose docs recommend the backup before every upgrade and advise checking .env.example for new variables afterwards. Confirm with your own platform owner which plugin daemon, API and sandbox behaviors changed, since security changes in recent releases affected agent sandbox networking and service-to-service authentication.
Then confirm compatibility for each plugin on the approved list. Check the vendor or internal owner's statement of support for the target Dify version, and re-run the approved version in a staging workspace that mirrors production settings, including the plugin installation policy and signature checks. Watch for plugins that stop loading, lose credentials after a schema change, or need a newer version to work. If a plugin fails, the choice is to hold the upgrade, pin the older plugin only where it still works, or remove the plugin from the approved list for all workspaces. Record each decision so auditors can see what was tested against which release.
Plan this loop as a recurring operating cost, not a one-time project. Minor releases have arrived roughly monthly, so the re-review, staging test and rollback rehearsal repeat on that rhythm for as long as you run Dify. Ask any implementation partner to price this as a retainer line item or a per-release task, and ask what is included: release review, staging re-test, backup verification and documentation of the approved list. Your own team should budget named owners and calendar time for it, since skipping a cycle leaves the approved list describing software you no longer run.
How DeployOpen scopes and delivers a Dify plugin policy
DeployOpen plans, implements and hands over Dify plugin installation policy for self-hosted deployments inside your own infrastructure. We start from which plugin sources your organization trusts, then build and document the controls that enforce that choice across current and future workspaces.
How we scope
- Engagements are fixed-scope, with the policy tier, workspace inventory and approved plugin list agreed in writing first.
- We record which plugin sources are allowed: all, official and partner, or Marketplace-only, with the reasoning behind each.
- Scope names the Dify edition, workspace count and who approves plugin requests, so ownership is clear before build starts.
How we build
- We map the approved plugin version set and the process for adding, updating or removing a plugin in each workspace.
- We test that installation restrictions hold for a newly created workspace, not only for workspaces that exist today.
- We check plugin installs against the license and access model, and confirm controls with your own administrators in your environment.
How we hand over
- You receive a written policy, a plugin approval record and the runbook for adding plugins across workspaces.
- Handover covers test evidence showing which sources are blocked and which approved versions are installed.
- We walk your platform and security teams through the upgrade steps that could change plugin behavior before each Dify release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering plugin reviews after each Dify release.
- Retainer work can include re-testing the policy after a new workspace is created or a plugin version changes.
- Questions about the Dify Enterprise edition, its licensing or features are confirmed with Dify directly before we commit to them.
