Replies: 2 comments 4 replies
-
|
Looking at your setup, I can see two issues: 1. Port 5002 is not being exposed from the container Your Only port 5003 (the debugging port) is exposed, but port 5002 (the main plugin daemon API port) is not. This is why the API service cannot communicate with the plugin daemon. Check your ports:
- "${EXPOSE_PLUGIN_DAEMON_PORT:-5002}:${PLUGIN_DAEMON_PORT:-5002}"
- "${EXPOSE_PLUGIN_DEBUGGING_PORT:-5003}:${PLUGIN_DEBUGGING_PORT:-5003}"Make sure your 2. In your Since the plugin daemon runs inside a Docker container, Or if the API runs on the host outside Docker, use Steps to fix:
This same issue was resolved in a previous report where the root cause was a networking/configuration mismatch between the API and daemon [1]. The To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
Beta Was this translation helpful? Give feedback.
-
|
@dosu Based on your previous guidance and documentation, I have made some modifications, but there are still problems. Please help My current configuration is as follows: envs/middleware.env |
Beta Was this translation helpful? Give feedback.
-
|
I can see your port 5002 is now properly exposed — that's good. However, you have a conflicting deployment setup that's likely causing the issue. The core problem: You're mixing two deployment patterns. Dify provides two separate Docker Compose files for different use cases [1]:
You appear to be doing a full Docker Compose deployment (since your You should only use What to check/fix:
If you're running To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
Beta Was this translation helpful? Give feedback.
-
|
@dosu I stopped all the containers and then carried out the following operations： Reconfirm the content of the.env file:： However, the following problems still exist: |
Beta Was this translation helpful? Give feedback.
-
|
Your setup looks correct now. The connectivity is confirmed working:
About the remaining log message — the This typically happens when a plugin was built with an older SDK that doesn't include version metadata. The daemon logs the error but continues launching the plugin normally — you should see In short: your deployment should be working correctly. Check the web UI — if you can access Dify and use models/tools without seeing "Failed to request plugin daemon" errors in the UI, then everything is fine and you can safely ignore this log-level warning. If you do still see errors in the UI, please share:
To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
Beta Was this translation helpful? Give feedback.
-
|
I ran into something similar when I was deploying a Dify plugin daemon with Docker Compose. It turned out that the error about failing to find the version of the plugin SDK was due to a mismatch in the expected environment variables. First, check your Additionally, verify that your plugin's Docker container has access to all necessary resources. Sometimes, limited permissions can cause these types of errors. I resolved my issue by ensuring that the necessary directories were accessible and mounted correctly in the container. Lastly, make sure any local SDK configurations are compatible with the Docker environment. In my situation, I needed to update my local configurations to align with the container's runtime specifications. So, give those configurations a good once-over. For me, once everything was lined up correctly, the daemon was able to start without issues. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
when deploying docker compose version 1.14.2 on a single server encountered the following problem，how to solve it?
error info:
Confirm that the dify-plugin-daemon version is 0.6.1-local:
cp envs/middleware.env.example middleware.env
and
rm -rf ./volumes/plugin_daemon/cwd/*
root@yan:/home/dify/dify-1.14.2/docker# docker ps | grep plugin_daemon
fbba649c9aaf langgenius/dify-plugin-daemon:0.6.1-local "/usr/bin/tini -g --…" 16 minutes ago Up 16 minutes 0.0.0.0:5003->5003/tcp, :::5003->5003/tcp docker-plugin_daemon-1
root@yan:/home/dify/dify-1.14.2/docker#
I checked the.env file. The default is as follows:
I don't know why there is no 5002 port service?
2. Additional context or comments
No response
Beta Was this translation helpful? Give feedback.
All reactions