langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Dify Milvus docker-compose Configuration Leads to Orphaned Service Exposure (milvus-minio/etcd) #15049

New Issue
Closed
opened 2026-02-21 19:19:57 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:19:57 -05:00
Owner
Copy Link
Copy Source

Originally created by @Yifeng-Wang on GitHub (Jul 1, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • 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.

Dify version

1.3.1 and till current main branch.

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. Set up Dify using Docker Compose
  2. Configure .env file with: VECTOR_STORE=milvus, MILVUS_URI=xxx # some intentionally incorrect/unreachable URI
  3. run: docker compose up -d
  4. Check container status with docker compose ps

✔️ Expected Behavior

Expected:

  • Bidirectional health dependencies: We perhaps want ensure that if the central milvus-standalone container is not running or exits, its tightly coupled supporting services (milvus-minio, milvus-etcd) also gracefully shut down.
  • No Orphaned Running Containers: No critical service (especially one with default weak credentials like Minio) should be left running as an "orphan" and exposed if its primary consumer/dependent service is not active.

In short, if milvus-standalone cannot start, milvus-minio and milvus-etcd should not remain in a running state forever, potentially exposing themselves.

❌ Actual Behavior

Actual Behavior:
milvus-standalone container fails to start (exits immediately) , but milvus-minio and milvus-etcd containers continue running indefinitely. They do not stop or exit despite their core consumer (milvus-standalone) being down.

This leads to the milvus-minio container (specifically) being active and accessible, with possibility exposing its default weak credentials (MINIO_ROOT_USER, MINIO_ROOT_PASSWORD) from the .env file.

Analysis of current design
There might be a flaw in dependency management for docker-compose.yaml regarding milvus for Dify.

  1. profile Mechanism Leading to Unconditional Service Startup
    All Milvus-related services (etcd, minio, milvus-standalone) utilize the same profile tag. This design ensures all services are unconditionally launched once the profile is active, regardless of whether the core milvus-standalone service can achieve or maintain a healthy running state. This means, even if milvus-standalone fails immediately, its dependencies will persist.

  2. Asymmetric Dependency Design
    milvus-standalone declares depends_on etcd and minio (ensuring etcd and minio start before milvus-standalone). This is the correct approach for startup dependency. However, etcd and minio services lack any mechanism to check milvus-standalone's ongoing health state, thus persist as "orphan" containers.

This perhaps violates the design principle that supporting services, whose sole purpose is to serve a core component, should not continue running and exposing themselves if that core component fails or is confirmed to be non-operational. The current behavior is perhaps counter-intuitive or document the behavior of Milvus dependencies behaviors.

Originally created by @Yifeng-Wang on GitHub (Jul 1, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.3.1 and till current main branch. ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. Set up Dify using Docker Compose 2. Configure .env file with: `VECTOR_STORE=milvus`, `MILVUS_URI=xxx # some intentionally incorrect/unreachable URI` 3. run: `docker compose up -d` 4. Check container status with `docker compose ps` ### ✔️ Expected Behavior **Expected:** - Bidirectional health dependencies: We perhaps want ensure that if the central milvus-standalone container is not running or exits, its tightly coupled supporting services (milvus-minio, milvus-etcd) also gracefully shut down. - No Orphaned Running Containers: No critical service (especially one with default weak credentials like Minio) should be left running as an "orphan" and exposed if its primary consumer/dependent service is not active. In short, if milvus-standalone cannot start, milvus-minio and milvus-etcd should not remain in a running state forever, potentially exposing themselves. ### ❌ Actual Behavior **Actual Behavior:** milvus-standalone container fails to start (exits immediately) , but milvus-minio and milvus-etcd containers continue running indefinitely. They do not stop or exit despite their core consumer (milvus-standalone) being down. This leads to the milvus-minio container (specifically) being active and accessible, with possibility exposing its default weak credentials (MINIO_ROOT_USER, MINIO_ROOT_PASSWORD) from the .env file. # **Analysis of current design** There might be a flaw in dependency management for docker-compose.yaml regarding milvus for Dify. 1. **`profile` Mechanism Leading to Unconditional Service Startup** All Milvus-related services (`etcd`, `minio`, `milvus-standalone`) utilize the same `profile` tag. This design ensures all services are unconditionally launched once the profile is active, regardless of whether the core `milvus-standalone` service can achieve or maintain a healthy running state. This means, even if `milvus-standalone` fails immediately, its dependencies will persist. 2. **Asymmetric Dependency Design** `milvus-standalone` declares `depends_on` `etcd` and `minio` (ensuring `etcd` and `minio` start *before* `milvus-standalone`). This is the correct approach for startup dependency. However, `etcd` and `minio` services lack any mechanism to check `milvus-standalone`'s ongoing health state, thus persist as "orphan" containers. This perhaps violates the design principle that supporting services, whose sole purpose is to serve a core component, should not continue running and exposing themselves if that core component fails or is confirmed to be non-operational. The current behavior is perhaps counter-intuitive or document the behavior of Milvus dependencies behaviors.
yindo added the 🐞 bug label 2026-02-21 19:19:57 -05:00
yindo closed this issue 2026-02-21 19:19:57 -05:00
yindo commented 2026-02-21 19:19:58 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jul 1, 2025):

Hi @Yifeng-Wang! I'm Dosu and I’m helping the dify team.

You've correctly identified a real limitation in the current Dify docker-compose setup for Milvus: if milvus-standalone fails, its dependencies (milvus-minio, milvus-etcd) keep running and may remain exposed, especially if default credentials are used. This is not a Dify-specific bug, but a result of how Docker Compose handles dependencies—depends_on only controls startup order, not shutdown or health propagation. There is no built-in mechanism in Compose to cascade shutdowns or monitor the health of a "core" service and stop its dependencies if it fails. The Dify compose files and documentation do not address this risk or provide mitigations, and there are no relevant PRs or issues proposing a fix for this behavior (docker-compose.yaml reference).

To mitigate this, consider: (1) customizing your Compose setup with a watchdog script or external monitoring that stops milvus-minio and milvus-etcd if milvus-standalone is not running, (2) using a more advanced orchestrator like Kubernetes for lifecycle management, (3) always changing default credentials and restricting network access to supporting services, and (4) limiting service exposure to only trusted networks. These steps can help reduce the risk of orphaned/exposed containers in your environment.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 1, 2025): <!-- Greeting --> Hi @Yifeng-Wang! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> You've correctly identified a real limitation in the current Dify docker-compose setup for Milvus: if `milvus-standalone` fails, its dependencies (`milvus-minio`, `milvus-etcd`) keep running and may remain exposed, especially if default credentials are used. This is not a Dify-specific bug, but a result of how Docker Compose handles dependencies—`depends_on` only controls startup order, not shutdown or health propagation. There is no built-in mechanism in Compose to cascade shutdowns or monitor the health of a "core" service and stop its dependencies if it fails. The Dify compose files and documentation do not address this risk or provide mitigations, and there are no relevant PRs or issues proposing a fix for this behavior [(docker-compose.yaml reference)](https://github.com/langgenius/dify/blob/a82943a83dbfea4f06b67d3fe16b4b4ffda2e35f/docker/docker-compose.yaml). To mitigate this, consider: (1) customizing your Compose setup with a watchdog script or external monitoring that stops `milvus-minio` and `milvus-etcd` if `milvus-standalone` is not running, (2) using a more advanced orchestrator like Kubernetes for lifecycle management, (3) always changing default credentials and restricting network access to supporting services, and (4) limiting service exposure to only trusted networks. These steps can help reduce the risk of orphaned/exposed containers in your environment. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/bc1b042c-c036-4327-b046-5b887bba5ef4?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/21778)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15049
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?