Upgraded your self-hosted Dify? Your .env may still have the SECRET_KEY everyone else has

Description and use

After upgrading Dify, the .env file may still contain a public SECRET_KEY that allows attackers to sign tokens. Replace it with a unique key to secure sessions, JWTs, and OAuth credentials.

Problem

After upgrading Dify, the .env file may still contain a public SECRET_KEY that was shipped with older releases, allowing attackers to sign tokens and compromise the instance.

Outcome

Replacing the public SECRET_KEY secures the Dify instance against token forgery and credential compromise, while also prompting necessary user notifications and re-authorizations.

Workflow

• 1. Verify if the old key is present: grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env
• 2. If count is 1, replace the key: cd dify/docker && cp .env .env.bak && sed -i "s|^SECRET_KEY=.*|SECRET_KEY=$(openssl rand -base64 42)|" .env && docker compose up -d
• 3. Inform users that changing the key will log them out and invalidate file URLs and OAuth integrations.
• 4. Optionally adjust other .env settings: expose ports, set CONSOLE_CORS_ALLOW_ORIGINS, set INIT_PASSWORD, and change default Postgres/Redis passwords.

Evidence

Up to Dify 1.14.x, docker/.env.example shipped a fixed SECRET_KEY, a long string starting sk-9f73s3lj

Source

What the key does, from Dify's environment variable docs: it's used for "session cookie signing, JWT authentication tokens, file URL signatures (HMAC-SHA256), and encrypting third-party OAuth credentials"

Source

Changing the key "will immediately log out all users, invalidate all file URLs", and OAuth-based plugin integrations must be authorized again because "their encrypted credentials become unrecoverable"

Source