> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise-docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Plugins Management

Plugins Management is the core console for extending enterprise AI capabilities. It is designed to serve as an **enterprise plugin lifecycle management center**. Through centralized administration, organizations can address plugin version fragmentation, “black-box” operations, and high security governance costs—enabling centralized installation, unified operations/monitoring, and global security policy control.

## 1. Overview

In enterprise web applications, plugins carry key extensibility capabilities such as LLM providers, tools, agent strategies, data sources, and triggers. Plugin Management primarily addresses the following pain points:

* **Version fragmentation**: The same plugin runs at different versions across workspaces, making troubleshooting difficult.
* **Black-box operations**: Lack of centralized visibility into running plugin instances (Pod resources, environment variables, load, etc.).
* **Missing governance**: No global policy control, making it hard to restrict installations from untrusted sources.

### 1.1 Value

* **Centralized lifecycle management**: Admins can install plugins with one click, switch versions, and bulk distribute/uninstall across workspaces.
* **Out-of-the-box experience**: Preinstall plugins for workspaces to reduce repeated setup by business teams.
* **Visual operations & monitoring**: Instance-level resource monitoring for Kubernetes (CPU, memory, network), with dynamic scaling support.
* **Security risk control**: Strictly control installation sources and publisher identity via a policy engine.

### 1.2 Use cases

* **Standardized platform**: IT wants to provide a standard toolset for all teams (e.g., Google Search, internal API tools).
* **Resource tuning**: For high-traffic plugins (e.g., LLM plugins), admins monitor load and adjust Pod counts for peak traffic.
* **Security & compliance**: Only allow plugins from “official” or “partner” sources; prevent arbitrary local uploads.

### 1.3 Key concepts

**Plugin types**

* **Model (LLM) plugins**: e.g., OpenAI, Claude, Gemini.
* **Tool plugins**: e.g., Google Search, GitHub, web scraping tools.
* **Agent strategy plugins**: e.g., Function Calling, ReAct, and other reasoning/execution strategies.
* **Extension plugins**: e.g., sensitive content moderation, external database connectors.
* **Datasource plugins**: e.g., Notion, Google Drive data connectors.
* **Trigger plugins**: e.g., Gmail Trigger, Outlook Trigger.

**Runtime entities**

* **Instance**: A running entity of a plugin in the system. Instances are isolated and can be restarted, rebuilt, or rolled back.
* **Pod**: The smallest runtime unit (in Kubernetes). It hosts the plugin container and exposes observable CPU/memory/network metrics.

## 2. How to use

### 2.0 Quick start

A typical Plugin Management workflow is: **Install plugin (Marketplace/local) > Assign (install) to workspaces > Monitor & operate > Uninstall/reclaim**.

1. **Install a new plugin**\
   On the “Plugin Management” page, click **Install Plugin**, then choose to download from the Marketplace or upload a local package to add it to the repository.
2. **Assign to workspaces**\
   In the plugin list, click **Install Management**, then click **Add installation target** and select the target workspaces. The system will deploy the plugin for those workspaces for an “install-and-use” experience.
3. **Monitor runtime status (K8s only)**\
   Click **···** on the right side of the plugin > **View Instances** to see load monitoring charts. If there is a performance bottleneck, increase CPU/memory limits or Pod count in **Resource Configuration**.

### 2.1 Install plugins

The system supports two installation methods, depending on your deployment environment and security policies.

**Option 1: Install from Marketplace (recommended)**

1. Click **Install Plugin** > **Marketplace**.
2. Browse the Marketplace in the popup window or a new tab.
3. Select the plugin and the desired version.
4. Click **Install**. The system will pull and deploy the base instance in the background.

**Option 2: Install a local plugin**

1. Click **Install Plugin** > **Local Plugin**.
2. Upload the plugin package file.
3. The system validates signatures and policies. If the uploaded plugin does not comply, the system will show a warning based on your settings (policies enforce restrictions at the workspace level; the admin console only warns and does not block installation).

### 2.2 Installation management (assignment & version control)

Admins can control where plugins are deployed and which versions are used across workspaces.

1. In the plugin list, find the target plugin and click **Install Management**.
2. Install this version to more workspaces: click **Add installation target**, then select workspaces in the list.
3. Uninstall this version from a workspace: either select the workspace in the list and click the uninstall icon, or click **Add installation target** and uncheck the workspace in the list.
4. **Version change indicators**: the system uses colors to highlight version changes:
   * **Gray (Installed)**: This plugin is already installed.
   * **Green (New)**: First-time installation.
   * **Blue (Upgrade)**: Upgraded from a lower version to the current one (e.g., 1.0.0 -> 1.2.0).
   * **Orange (Downgrade)**: Downgraded from a higher version to the current one (e.g., 1.3.0 -> 1.2.0).
   * **Light blue (Overwrite)**: Same version overwrite (shows plugin version checksum, e.g., 1.2.0 SHA-256: 3db71aca).
5. The bottom of the dialog shows a preview of changes (new, upgrade, downgrade, overwrite install, uninstall). Click **Confirm** to apply immediately.

### 2.3 Runtime monitoring & configuration (K8s only)

In a Kubernetes deployment, admins have advanced operations capabilities. Docker Compose environments do not currently support this section.

In the plugin list, click **...** > **View Instances** to open the details page.

**1. Load monitoring**

Visualize Pod/container runtime data for the past 1 hour, 1 day, or 1 week:

* CPU usage
* Memory usage
* Network upload/download rate
* Note: You can use quick actions to compare the same container type across different Pods. Charts display resource limit lines (Limit).

**2. Resource configuration**

Adjust the maximum resource limits for each container:

* **CPU cores**: Supports values less than 1 core.
* **Memory**: Set the maximum memory limit.
* After changes, click **Save and Apply**. The system will restart instances for the changes to take effect.
* Note: Ensure the cluster has sufficient resources; otherwise the resource update may not take effect.

**3. Instance management & scaling**

* **Scale up/down**: In the instance list, hover over **Pod count** to manually increase or decrease Pods to handle traffic changes.
* **Restart instances**: Restart all Pods; performance may briefly degrade.
* **Rebuild instances**: Pull the latest dependencies and build a fresh instance environment.
* **Rollback instances**: Roll back the current runtime to a historical instance version (note: the current instance will be lost).
* Note: Ensure sufficient cluster resources before scaling up; otherwise new Pods may fail to start.

**4. Environment variables**

Configure instance-level environment variables. By default, instances inherit global settings, but you can override them.

* Note: Ensure sufficient cluster resources; otherwise environment variable updates may not take effect.

### 2.4 Uninstall plugins

Uninstallation is divided into **uninstall from a workspace** and **global uninstall**.

**Safe uninstall checks**

To prevent accidental outages, the system performs dependency checks during uninstall:

* **Tool / Agent strategy / Trigger plugins**: the system lists **Apps** and **Knowledge Pipelines** that are using the plugin.
* **Model / Datasource / Extension plugins**: the system lists **workspaces** that are using the plugin.

Admins can click **Export list** to back up the impacted list and proceed only after confirmation.

### 2.5 Plugin installation policy

Admins can define policies to enforce enterprise plugin security boundaries.

Path: top of the Plugin Management page > **Plugin Installation Policy**

* **Allowed installation sources**: choose **All**, **Official & Partners**, **Official only**, or **None** (disallow all sources).
* **Restrict to Marketplace only**: when enabled, local upload installation is blocked to prevent malicious code injection.
* [For more details, see Plugin Installation Policy](/versions/3-0-x/zh-cn/administrator-guide/plugins-management)

## 3. Troubleshooting

* **Installation failed**: Click the **Installation Logs** icon above the list to view detailed error logs. Common causes include network timeouts, checksum mismatch, or dependency conflicts.
* **Instance stuck in Building**: This is an intermediate state during rebuild or creation. If it does not transition to Running for a long time, check whether the Kubernetes cluster has sufficient resources.
* **Monitoring data not shown**: Confirm that your deployment is Kubernetes. Docker Compose mode does not support Pod metrics.
* **Rollback unavailable**: If the currently running instance is the same target instance, the rollback button is disabled.
* **New Pods cannot start**: Likely due to insufficient cluster resources. Check Kubernetes capacity and either scale the cluster or remove other plugins.
* **Environment variable update failed**: Likely due to insufficient cluster resources. Check Kubernetes capacity and either scale the cluster or remove other plugins.
* **Resource configuration update failed**: Likely due to insufficient cluster resources. Check Kubernetes capacity and either scale the cluster or remove other plugins.

## 4. FAQ

### What’s the difference between Docker Compose and Kubernetes (K8s) deployments?

Kubernetes supports the full feature set, including instance resource monitoring (CPU/memory), Pod scaling, rolling updates, and advanced operations. In Docker Compose environments, **View Instances**, **Resource Configuration**, and Pod-related monitoring are not available—only basic install/uninstall and version management are supported.

### What happens to apps after a plugin is uninstalled?

If an admin forcibly uninstalls a plugin that an app depends on, the app will error at runtime with: “The plugin is not installed and cannot be used!”, causing disruption. Always review the impact scope in the confirmation dialog before uninstalling.

### What are “global instance environment variables”?

These are variables configured at the top of the admin console. All newly started plugin instances inherit these global variables by default. You can override them for a specific plugin under **View Instances** > **Environment Variables**.

### Why can’t I see updates for some plugins?

Check **Plugin Installation Policy**. If the policy restricts installations to “Official” plugins only, updates from non-official sources may not be visible or installable. Also verify that your Marketplace connection is healthy.

## 5. Best practices

* **Strict source restrictions in production**: In production, set the policy to **Official only** and enable **Restrict to Marketplace only** to minimize security risk.
* **Resource reservation & monitoring**: For critical LLM model plugins, run load tests before go-live and configure Min/Max Pod counts and resource limits based on monitoring charts to avoid slow responses during peak traffic.
* **Smooth upgrades**: When upgrading versions, do a canary rollout in a test workspace first (install the new version only in that workspace). After compatibility is validated, use **Install Management** to roll out in bulk.
* **Regularly clean up failed records**: Periodically remove historical failed entries in installation logs to keep the operations view tidy.