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

Description and use

After upgrading Dify, the .env may still contain a public SECRET_KEY that lets attackers forge tokens. Replacing it secures the instance but logs out users and invalidates file URLs.

Problem

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

Outcome

Replacing the public SECRET_KEY protects the instance from token forgery, invalidates existing sessions and file URLs, and requires OAuth integrations to be reauthorized.

Workflow

• Check if the .env contains the old key using grep
• If present, back up the .env
• Generate a new key with openssl rand -base64 42 and replace the line in .env
• Restart the containers with docker compose up -d
• Notify users of logout and reauthorization requirements

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