adout volumes

[zhouji1026]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

/dify/docker/volumes/plugin_daemon/assets/
/dify/docker/volumes/plugin_daemon/cwd/
/dify/docker/volumes/plugin_daemon/images/
/dify/docker/volumes/plugin_daemon/persistence/
/dify/docker/volumes/plugin_daemon/plugin/
/dify/docker/volumes/plugin_daemon/plugin_packages/

May I ask what these directories do, and what are they associated with?
Then may I ask if installing a plugin causes changes in the backend data tables, and what associations do the tables have?

[dosubot[bot]]

@zhouji1026 Here's what I found about these directories and the related database tables.

Plugin Daemon Volume Directories

The plugin_daemon service mounts ./volumes/plugin_daemon to /app/storage inside the container [1]. The subdirectories are configured via environment variables:

Directory	Env Variable	Purpose
assets/	PLUGIN_MEDIA_CACHE_PATH	Stores plugin media assets like icons and images. Managed via PluginAssetManager for fetching/extracting plugin resources [2]
cwd/	PLUGIN_WORKING_PATH	Working directory for plugin execution and shell sessions
plugin/	PLUGIN_INSTALLED_PATH	Stores the actual installed plugin code and resources
plugin_packages/	PLUGIN_PACKAGE_CACHE_PATH	Caches plugin package files (.difypkg) for installation/upgrades
persistence/	—	Used for plugin persistent data storage
images/	—	Not explicitly referenced in available code; may be used internally by the daemon

Database Tables Affected by Plugin Installation

When you install a plugin, several tables are involved:

1. account_plugin_permissions — Controls who can install/debug plugins per workspace (install_permission, debug_permission) [3]

2. tenant_plugin_auto_upgrade_strategies — Stores auto-upgrade settings per tenant (strategy, time of day, include/exclude lists) [4]

3. tool_builtin_providers — Stores tool provider configurations and encrypted credentials per tenant [5]

4. tool_oauth_system_clients / tool_oauth_tenant_clients — Store OAuth credentials at the system level and tenant level respectively for tool-type plugins [6]

Note that the plugin daemon is a separate service that communicates with the Dify API via HTTP [7], so some internal plugin state (like the actual plugin registry/manifest tracking) may be managed entirely within the daemon's own storage rather than in the main Dify database. The directories persistence/ and images/ fall into this category — they're likely managed internally by the daemon process.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[zhouji1026]

select * from plugin_declarations where plugin_id like '%word_generator%'; select * from tool_installations where plugin_id like '%word_generator%'; select * from tenant_storages where plugin_id like '%word_generator%'; select * from plugins where plugin_id like '%word_generator%'; Every time I install a plugin, it installs instantly. If the pie progress bar doesn't appear, there's a problem. Then I go back to dify_plugin to delete the records from these tables, then go to the plugin/plugin_packages/ directory to delete the records, and restart the plugin container May I ask what these tables mean, and what are their connections? Also, why do plugins appear to be installed instantly? 是周周啊。 ***@***.*** 原始邮件 发件人：dosubot[bot] ***@***.***> 发件时间：2026年6月10日 16:31 收件人：langgenius/dify ***@***.***> 抄送：zhouji1026 ***@***.***>, Mention ***@***.***> 主题：Re: [langgenius/dify] adout volumes (Discussion #37274) @zhouji1026 Here's what I found about these directories and the related database tables. Plugin Daemon Volume Directories The plugin_daemon service mounts ./volumes/plugin_daemon to /app/storage inside the container [1]. The subdirectories are configured via environment variables: DirectoryEnv VariablePurpose assets/PLUGIN_MEDIA_CACHE_PATHStores plugin media assets like icons and images. Managed via PluginAssetManager for fetching/extracting plugin resources [2] cwd/PLUGIN_WORKING_PATHWorking directory for plugin execution and shell sessions plugin/PLUGIN_INSTALLED_PATHStores the actual installed plugin code and resources plugin_packages/PLUGIN_PACKAGE_CACHE_PATHCaches plugin package files (.difypkg) for installation/upgrades persistence/—Used for plugin persistent data storage images/—Not explicitly referenced in available code; may be used internally by the daemon Database Tables Affected by Plugin Installation When you install a plugin, several tables are involved: account_plugin_permissions — Controls who can install/debug plugins per workspace (install_permission, debug_permission) [3] tenant_plugin_auto_upgrade_strategies — Stores auto-upgrade settings per tenant (strategy, time of day, include/exclude lists) [4] tool_builtin_providers — Stores tool provider configurations and encrypted credentials per tenant [5] tool_oauth_system_clients / tool_oauth_tenant_clients — Store OAuth credentials at the system level and tenant level respectively for tool-type plugins [6] Note that the plugin daemon is a separate service that communicates with the Dify API via HTTP [7], so some internal plugin state (like the actual plugin registry/manifest tracking) may be managed entirely within the daemon's own storage rather than in the main Dify database. The directories persistence/ and images/ fall into this category — they're likely managed internally by the daemon process. To reply, just mention @dosu. Share context across your team and agents. Try Dosu. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.

[dosubot[bot]]

@zhouji1026 Good question. The tables you're querying (plugin_declarations, tool_installations, tenant_storages, plugins) are managed by the Plugin Daemon service — not the main Dify API database. This is an important distinction in Dify's architecture.

How It Works

Dify uses a separate Plugin Daemon (running on port 5002) that has its own database. The main Dify API communicates with this daemon via REST API [1]. Here's what those tables likely represent:

Table	Purpose
plugins	Core plugin registry — records each installed plugin's identity and metadata
plugin_declarations	Stores plugin manifests (version, author, name, description, capabilities, resource requirements)
tool_installations	Tracks which plugins are installed for which tenant
tenant_storages	Manages per-tenant persistent storage allocated to plugins

These tables are interconnected by plugin_id — when you install a plugin, the daemon creates records across all of them to register the plugin, store its declaration, track the installation per tenant, and allocate storage.

Why Plugins Appear to Install "Instantly"

The installation has two phases [2]:

1. Download/Upload (synchronous) — the package is fetched from marketplace/GitHub or uploaded
2. Installation (asynchronous) — the daemon extracts and registers the plugin, tracked via task polling every ~5 seconds [3] [4]

If the progress bar never appears, it likely means:

• The package was already cached in plugin_packages/ from a previous attempt (the system checks before re-downloading) [2]
• The package is small enough to extract and register within one polling interval (~5 seconds)
• Or the installation is failing silently and the task completes with an error state that isn't surfaced properly

Your Manual Cleanup Workflow

Your approach of deleting records from those 4 tables + removing files from plugin/ and plugin_packages/ + restarting the container is correct for a full reset. The relationship is:

plugin_packages/  →  contains the .difypkg file (cached download)
plugin/           →  contains extracted plugin code (runtime files)
plugins table     →  plugin identity record
plugin_declarations →  manifest/capabilities
tool_installations  →  tenant-to-plugin binding
tenant_storages     →  plugin persistent data allocation

If plugins keep appearing "instant" without a progress animation, it suggests the daemon is completing too quickly (cached packages) or the frontend isn't properly polling. You might want to check the plugin daemon logs for errors during the installation phase to see if something is failing silently.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.