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

Unify environment variables for PostgreSQL and MySQL connections and authentication #20756

New Issue
Closed
opened 2026-02-21 20:08:50 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 20:08:50 -05:00
Owner
Copy Link
Copy Source

Originally created by @BorisPolonsky on GitHub (Dec 2, 2025).

Originally assigned to: @BorisPolonsky on GitHub.

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

In the current version, pluginDaemon shares the same conventions for username and password convention for postgresql (DB_USERNAME and DB_PASSWORD). This convention also suits the api conponent when using postgresql as database, which makes configuration easier when deploying with k8s as they may share the same ConfigMap or Secret can be shared among different components. We'd like to propose that api shares the convention above as well when MySQL is used by changing definition of environment variables as well:

  • MYSQL_USERNAME -> DB_USERNAME
  • MYSQL_PASSWORD -> DB_PASSWORD

2. Additional context or comments

Besides username and password, all database related configurations shares the same convention in plugin daemon regardless of the actual DB being used, which is a good thing to adopt in api.
https://github.com/langgenius/dify-plugin-daemon/blob/d3d1a652e65f3eff006368b513207aefb1594b4d/internal/db/init.go#L64-L93

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @BorisPolonsky on GitHub (Dec 2, 2025). Originally assigned to: @BorisPolonsky on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. In the current version, `pluginDaemon` shares the same conventions for username and password convention for postgresql (`DB_USERNAME` and `DB_PASSWORD`). This convention also suits the api conponent when using postgresql as database, which makes configuration easier when deploying with k8s as they may share the same `ConfigMap` or `Secret` can be shared among different components. We'd like to propose that api shares the convention above as well when MySQL is used by changing definition of environment variables as well: - `MYSQL_USERNAME` -> `DB_USERNAME` - `MYSQL_PASSWORD` -> `DB_PASSWORD` ### 2. Additional context or comments Besides username and password, all database related configurations shares the same convention in plugin daemon regardless of the actual DB being used, which is a good thing to adopt in api. https://github.com/langgenius/dify-plugin-daemon/blob/d3d1a652e65f3eff006368b513207aefb1594b4d/internal/db/init.go#L64-L93 ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 20:08:50 -05:00
yindo closed this issue 2026-02-21 20:08:50 -05:00
yindo commented 2026-02-21 20:08:50 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 2, 2025):

cc @laipz8200

I think this is reasonable, however we should make sure the changes won't affect the existing users.

@crazywoola commented on GitHub (Dec 2, 2025): cc @laipz8200 I think this is reasonable, however we should make sure the changes won't affect the existing users.
yindo commented 2026-02-21 20:08:50 -05:00
Author
Owner
Copy Link
Copy Source

@laipz8200 commented on GitHub (Dec 2, 2025):

We actually use the unified configuration names. Where can you find the environment variables for MySQL?

@laipz8200 commented on GitHub (Dec 2, 2025): We actually use the unified configuration names. Where can you find the environment variables for MySQL?
yindo commented 2026-02-21 20:08:50 -05:00
Author
Owner
Copy Link
Copy Source

@BorisPolonsky commented on GitHub (Dec 3, 2025):

We actually use the unified configuration names. Where can you find the environment variables for MySQL?

https://github.com/langgenius/dify/blob/9b9588f20df3c4c0f650324c8c9a6f041233b4bb/docker/docker-compose.yaml#L462-L464

It's in the shared-api-worker-env section in docker-compose.yaml. I've checked again and found out that it's defined yet unused in the application. Shall we remove MYSQL_USERNAME, MYSQL_PASSWORD and MYSQL_DATABASE from this section somehow to avoid confusion?

@BorisPolonsky commented on GitHub (Dec 3, 2025): > We actually use the unified configuration names. Where can you find the environment variables for MySQL? https://github.com/langgenius/dify/blob/9b9588f20df3c4c0f650324c8c9a6f041233b4bb/docker/docker-compose.yaml#L462-L464 It's in the `shared-api-worker-env` section in `docker-compose.yaml`. I've checked again and found out that it's defined yet unused in the application. Shall we remove `MYSQL_USERNAME`, `MYSQL_PASSWORD` and `MYSQL_DATABASE` from this section somehow to avoid confusion?
yindo commented 2026-02-21 20:08:50 -05:00
Author
Owner
Copy Link
Copy Source

@laipz8200 commented on GitHub (Dec 3, 2025):

@BorisPolonsky

Yes, we need to remove them from the .env.example file and re-generate our Docker Compose file. Would you mind submitting a PR for this?

@laipz8200 commented on GitHub (Dec 3, 2025): @BorisPolonsky Yes, we need to remove them from the .env.example file and re-generate our Docker Compose file. Would you mind submitting a PR for this?
yindo commented 2026-02-21 20:08:50 -05:00
Author
Owner
Copy Link
Copy Source

@BorisPolonsky commented on GitHub (Dec 3, 2025):

@BorisPolonsky

Yes, we need to remove them from the .env.example file and re-generate our Docker Compose file. Would you mind submitting a PR for this?

I'll see what I can do.

@BorisPolonsky commented on GitHub (Dec 3, 2025): > [@BorisPolonsky](https://github.com/BorisPolonsky) > > Yes, we need to remove them from the .env.example file and re-generate our Docker Compose file. Would you mind submitting a PR for this? I'll see what I can do.
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 💪 enhancement
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#20756
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?