Use the format your framework expects
An APP_KEY, an AUTH_SECRET and a SECRET_KEY are not interchangeable configuration values. Choose the framework first, then generate a separate secret for each application and environment. These are the defaults used by our tools, not universal minimum requirements.
| Framework | Variable | Default output |
|---|---|---|
| Auth.js / NextAuth | AUTH_SECRET / NEXTAUTH_SECRET | 32 random bytes in standard base64 |
| Django | SECRET_KEY | 50 characters from Django's alphabet |
| Laravel | APP_KEY | base64: prefix + 32 bytes for AES-256-CBC |
| Flask | SECRET_KEY | 32 random bytes as 64 hex characters |
| Rails | SECRET_KEY_BASE | 64 random bytes as 128 hex characters |
| Strapi | APP_KEYS and separate salts / JWT secrets | Multiple independent values in an .env block |
| Symfony | APP_SECRET | 16 random bytes as 32 hex characters |
Generate inside your project
Use the framework CLI where one exists. The Django and Rails commands require their project dependencies; the Python secrets and PHP commands use the language runtime.
# Auth.js
npx auth secret
# Django
python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
# Laravel: writes APP_KEY to the project's environment file
php artisan key:generate
# Flask
python -c "import secrets; print(secrets.token_hex(32))"
# Rails
bin/rails secret
# Symfony
php -r 'echo bin2hex(random_bytes(16)), PHP_EOL;'
Use framework documentation for the version you deploy: Auth.js, Django, Laravel, Flask, Rails, Strapi and Symfony.
A new deployment should usually keep the existing secret
Generate when creating an application or deliberately rotating its credentials. Generating a new secret every time a container starts can break sessions between replicas and invalidate data created before a restart. Configure replicas of the same application to use the same active key set.
Plan rotation around what the key protects
A signing key change can invalidate cookies or signed links. An encryption key change can make stored data unreadable if the previous key is discarded. Keep old keys only for the required migration window and use your framework's documented fallback mechanism; do not invent a comma-separated format for a setting that expects one string.
For example, Django exposes SECRET_KEY_FALLBACKS and Flask exposes SECRET_KEY_FALLBACKS for supported uses. Laravel supports previous encryption keys. Check which components and extensions honor fallback keys before relying on a seamless transition.
A generated secret is not a third-party API credential
These tools create values for software you control. They cannot issue a working API key for another service or replace the client secret supplied by an OAuth provider. Get provider-issued credentials from that provider's dashboard.