You can first follow the steps below to troubleshoot and “brake,” trying to avoid using the POST interface you mentioned that requires Authorization.
1. First, confirm if the plugin daemon process is still frantically retrying
Execute on the deployment server (you’ve been prompted once before):
docker logs docker-plugin_daemon-1 -n 200
Check if recent logs are constantly repeating similar entries:
- A certain plugin install task
- Constantly reporting
Task timed out but not properly terminated
If so:
- It’s very likely that a certain “installing” task is stuck, and the plugin daemon is constantly retrying.
To “brake” first, you can temporarily stop this container:
docker stop docker-plugin_daemon-1
This can first prevent the continuous refreshing of failed installation records.
(Then restart: docker start docker-plugin_daemon-1)
2. Without using the POST interface, how to get local Authorization?
Even with local deployment, the frontend will still carry a Bearer Token when accessing Dify; the browser just passes it for you.
You can get this token this way, and then use it to call the POST interface you saw in another post (the “clean up plugin installation status” interface):
- Open your Dify webpage in a browser (e.g.,
http://localhost:3000or your own domain) and log in normally. - Open browser developer tools:
- Chrome/Edge:
F12→ Select the “Network” tab.
- Chrome/Edge:
- Click on any page that accesses the backend (e.g., enter “Studio”, “Apps”, etc.).
- In the Network panel, find an interface with a request path similar to
/console/api/...and click on it. - In “Headers”, find the
Authorizationfield, which is usually:Authorization: Bearer xxxxxxx... - Copy out the long string of token after
Bearer. (Be careful not to leak it to others)
This way you will have the Authorization value for your local deployment, and you can call that repair interface just like with the cloud version.
3. Using the obtained Token to call the “clean up installing tasks” interface
You should have already seen the specific interface path and method in the post you referenced, which is usually a POST request.
You can use curl (on the server) to send it:
curl -X POST "http://<your_backend_address>/xxx/xxx" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <the token you just copied>" \
-d '{
// Fill in the body according to that post
}'
Note a few things:
<your_backend_address>: If you are using default docker-compose, it’s usually:- Access from host browser:
http://<server_IP>:3000 - But the actual API backend port might be 5001/8000, etc., which needs to match your own configuration (check the API service mapping in
docker-compose.yml).
- Access from host browser:
- The interface path and body parameters must strictly follow the post you referenced (to avoid accidentally deleting other records).
After a successful call, refresh the Dify page. Usually:
- The “Installing Plugin” prompt in the top right corner will disappear;
- The Tongyi plugin will become “Not Installed” or a failed state, and you can try reinstalling it later (it’s recommended to troubleshoot image/network issues first).
4. If you really cannot/do not want to use the API, you can consider a more “hardcore” approach (use with caution)
This method carries higher risks and is only suitable if you have some database operation experience and are willing to perform database backups:
- Stop Dify related containers (to avoid write conflicts)
docker compose down - Back up data in the database container (Postgres):
- Find the Postgres container name, e.g.,
docker psshowsdify-postgres-1; - Use
pg_dumpto export:docker exec -t dify-postgres-1 pg_dump -U <db_user> <db_name> > dify_backup.sql
- Find the Postgres container name, e.g.,
- Enter the database, find the table related to “plugin installation tasks”, and change the status from
installing/pendingtofailedor directly delete that record.
However, because table structures and field names may vary across different versions, if you reach this step, it’s best to post your version number from docker-compose.yml, database information, and a section of the relevant table structure for further discussion, to avoid incorrect operations.
5. I suggest you can now reply to the post with two things
-
Execute on the server:
docker logs docker-plugin_daemon-1 -n 200Paste the key error (including a few lines above and below
Task timed out but not properly terminated) into the post. -
Following step 2 above, get
Authorization: Bearer ...in your browser, confirm you can capture the token, and if you have questions, you can post a screenshot of the redacted request headers.
With this information (logs + your version (1.11.4)), if it still gets stuck later, it will be possible to more accurately determine if it’s a known issue with the current version, or a problem with the Tongyi plugin’s own installation (e.g., network, Python source, image).
Potentially helpful documentation (related to the issue)
- Self-hosting deployment (including docker-compose structure explanation):
Deploy Dify with Docker Compose - Dify Docs
Version Information
- You are currently on v1.11.4. The plugin system is relatively mature, but issues related to plugin installation/dependency installation are continuously being fixed in subsequent versions. If the official Release notes later mention fixes for issues like “plugin installation timeout/stuck in installation”, it is recommended to consider upgrading if conditions permit.