v0.0.34
SECRET_KEY and ENCRYPTION_KEY are now required and validated at startup
The application no longer accepts publicly known default secrets. On startup, it refuses to boot if:
- SECRET_KEY is empty, too short, or still set to the old public default (
your-super-secret-key-change-in-production-min-32-chars) - ENCRYPTION_KEY is empty or still set to the old public placeholder (
change_this_to_a_random_32_byte_hex_value)
This closes vulnerabilities where deployments left on public defaults could have authentication tokens forged, or stored credentials encrypted under a publicly known key (CWE-798).
Who is affected
Any deployment that never set its own SECRET_KEY or ENCRYPTION_KEY, or copied the old example values. These instances may fail to start after upgrading until valid secrets are configured.
Deployments already using strong, unique values for both keys are not affected.
Required action before upgrading
Generate a strong SECRET_KEY:
python -c "import secrets; print(secrets.token_urlsafe(32))"Generate a strong ENCRYPTION_KEY:
python -c "import secrets; print(secrets.token_hex(32))"Set them in your environment:
- Docker / Compose: set SECRET_KEY and ENCRYPTION_KEY in the host environment or the
.envfile next todocker-compose.yml. - Manual /
run.sh: set SECRET_KEY and ENCRYPTION_KEY in your.env.
For fresh manual installs, run.sh / deploy.sh can auto-generate missing empty keys. Existing deployments using the old ENCRYPTION_KEY placeholder will fail loudly instead of silently rotating the key.
Restart the application. With Compose restart: always, a missing or rejected key may cause a crash loop until valid values are provided.
Impact of changing SECRET_KEY
Changing SECRET_KEY invalidates all previously issued tokens, including:
- User access and refresh tokens
- Long-lived workflow HTTP bearer tokens used by curl or external integrations
- Temporary OAuth state, MCP session, and Playwright execution tokens
Users will need to log in again. Existing external integrations using workflow bearer tokens will receive 401 Unauthorized until their tokens are revoked, recreated, and updated in the calling systems.
Impact of changing ENCRYPTION_KEY
Changing ENCRYPTION_KEY can make previously encrypted stored credentials unreadable. No database rows are deleted, but affected credentials may need to be re-created or reconnected.
What's Changed
- fix/minor-ui-and-traces-improvements by @mbakgun in #132
- fix/minor-ui-improvements by @ckakgun in #134
- chore(deps-dev): Bump vitest from 3.2.4 to 4.1.0 in /frontend in the npm_and_yarn group across 1 directory by @dependabot[bot] in #138
- fix: parameterize node_id lookup in webhook handlers by @Joshua-Medvinsky in #131
- fix: require non-default JWT secret_key at startup by @Joshua-Medvinsky in #130
- update/readme-docs-and-version by @ckakgun in #139
New Contributors
- @Joshua-Medvinsky made their first contribution in #131
Full Changelog: v0.0.33...v0.0.34
