Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix Support per-service database credentials via DIFY_DB_USER / DIFY_DB_PASS overrides [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#34752•Fetched 2026-04-09 08:17:55
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
1
Author
lin-snowlin-snow
Participants
lin-snowlin-snow
Assignees
lin-snowlin-snow
Timeline (top)
assigned ×1cross-referenced ×1labeled ×1

Fix Action

Fixed

PR fix notes

PR #34753: feat: add DIFY_DB_USER/DIFY_DB_PASS env overrides for per-service DB credentials

Description (problem / solution / changelog)

[!IMPORTANT]

  1. Make sure you have read our contribution guidelines
  2. Ensure there is an associated issue and you have been assigned to it
  3. Use the correct syntax to link this PR: Fixes #<issue number>.

Summary

Fixes #34752 resolves ENG-164

Add DIFY_DB_USER and DIFY_DB_PASS as optional environment variable overrides for DB_USERNAME and DB_PASSWORD.

Why: Docker Compose cannot do per-service variable fallback inside a shared YAML anchor (x-shared-env). To support per-service DB credentials (e.g. least-privilege access), the fallback must happen in application code.

What changed (api/configs/middleware/__init__.py):

  • Added two optional fields DIFY_DB_USER / DIFY_DB_PASS (default None).
  • Added effective_db_username / effective_db_password computed properties that prefer the new vars when set, falling back to the originals.
  • Updated SQLALCHEMY_DATABASE_URI to use the effective values.

No breaking change — unset vars fall back to existing DB_USERNAME / DB_PASSWORD.

Screenshots

N/A (backend config only, no UI change)

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint and make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

Changed files

  • api/configs/middleware/__init__.py (modified, +21/-1)
RAW_BUFFERClick to expand / collapse

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 production deployments, it is common to assign per-service database credentials (e.g. dify-api gets a read-write user, worker gets a different user with limited privileges). Currently, api, worker, and worker_beat all share the same DB_USERNAME / DB_PASSWORD via the x-shared-env anchor in docker-compose.yaml.

Docker Compose does not support variable-level fallback or per-service override within a shared YAML anchor — you can only override the entire environment block, which defeats the purpose of x-shared-env. This means there is no clean way at the Compose layer to give individual services their own DB credentials while still sharing the rest of the env vars.

Proposed solution: Add two new optional environment variables DIFY_DB_USER and DIFY_DB_PASS in the DatabaseConfig (Pydantic settings). When set, they take precedence over DB_USERNAME / DB_PASSWORD; when unset, behaviour is unchanged (fallback to the originals). This allows operators to inject per-service credentials at the container level without duplicating the entire shared env block.

2. Additional context or comments

  • Only one file needs to change: api/configs/middleware/__init__.py.
  • Zero breaking change — existing deployments that don't set the new vars are unaffected.
  • The same DatabaseConfig is loaded by all three services (api / worker / worker_beat), so the override applies uniformly.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.

extent analysis

TL;DR

Add two new optional environment variables DIFY_DB_USER and DIFY_DB_PASS to the DatabaseConfig to allow per-service database credentials.

Guidance

  • Modify the DatabaseConfig (Pydantic settings) to include DIFY_DB_USER and DIFY_DB_PASS as optional environment variables.
  • Update the logic to prioritize DIFY_DB_USER and DIFY_DB_PASS over DB_USERNAME and DB_PASSWORD when set.
  • Change the api/configs/middleware/__init__.py file to implement the new environment variables.
  • Ensure the existing deployments without the new variables remain unaffected by maintaining the fallback behavior to DB_USERNAME and DB_PASSWORD.

Example

from pydantic import BaseSettings

class DatabaseConfig(BaseSettings):
    DB_USERNAME: str
    DB_PASSWORD: str
    DIFY_DB_USER: str | None = None
    DIFY_DB_PASS: str | None = None

    @property
    def username(self):
        return self.DIFY_DB_USER or self.DB_USERNAME

    @property
    def password(self):
        return self.DIFY_DB_PASS or self.DB_PASSWORD

Notes

The proposed solution requires careful consideration of the potential impact on existing deployments and the uniform application of the override across all services.

Recommendation

Apply workaround by adding the new environment variables to the DatabaseConfig, as this allows for per-service database credentials without introducing breaking changes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#latency issue#model loading#dependency error#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING