Maurice
44c92052a3
Every page was read against the code on dev. What changed: - Pages that described 4.2 behaviour: satellite view on the vector maps, the mobile journal timeline, Collab with its fifth tab, the Review badge, clustered pins on the share page, the Leaflet preset list, the strict guard on fe80::/10, the invite link tools and their scopes, the Public API scope rules, the permission count in the plugin SDK. - Features of this release that no page mentioned: videos in a journal entry, receipts on an expense, the Google transit backend, routing counters, the rating on a place, the navigation menu, car stops, the manual school holiday catalogue and its MCP tools, the Dawarich panel in the Atlas, the release notes modal, plugin frames going fullscreen, the corridor call into the search provider hook. - Statements that sent an admin the wrong way: DEFAULT_LANGUAGE is not in the Helm ConfigMap, env.PORT cannot be changed on the chart alone, the rotation script does not cover the document sync credentials, event handlers cannot broadcast, there is no per user MFA reset in the admin panel, the demo user can edit, an unparsable APP_URL stops the server. - Updating gets a section for 4.3.0: the TREK Places API as the new default, the new variables, the Overpass timeout, SSO sessions on an OIDC only instance, the migration that puts booked nights on the drive.
7.1 KiB
Encryption Key Rotation
What the encryption key protects
TREK encrypts sensitive settings at rest using AES-256-GCM. The following values are stored encrypted in the database:
- Google Maps API key (instance-wide, in
app_settings; the per-user column is still read as a fallback) - Unsplash access key (instance-wide, in
app_settings; the per-user column is still read as a fallback) - Amap API key (instance-wide, in
app_settings; the per-user column is still read as a fallback) - Mapbox access token (per user)
- CARTO API key (per user, in
settingstable) - OpenWeather API key (per user)
- Immich API key (per user)
- AirTrail API key (per user)
- Dawarich API key (per user, in
dawarich_connections) - Synology Photos password, session ID, and device ID (per user)
- Per-user webhook URL, ntfy notification token, and LLM provider API key (in
settingstable) - Instance-wide API key of the AI Parsing addon (in
addons.config) - Document sync credentials of a trip's stores, one encrypted blob per store and trip (in
document_connections), and the webhook secret of each binding (intrip_document_links); see Document-Sync - OIDC client secret (global, in
app_settings) - SMTP password (global, in
app_settings) - Admin webhook URL and admin ntfy token (global, in
app_settings) - MFA (TOTP) secrets for all users
- Photo passphrases for Synology shared-link photos (in
trek_photos) - Passphrases for shared trip album links (in
trip_album_links) - S3 storage backend secret access keys (in
app_settings['storage.backends']; see Admin-Storage) - Plugin OAuth access and refresh tokens, plus every plugin settings field the plugin's manifest marks
secret(instance scope inplugins.config, user scope inplugin_user_config.config)
The encryption derives a key from ENCRYPTION_KEY using SHA-256 (with a domain suffix per secret type), so the raw ENCRYPTION_KEY value is never stored in the database.
Key resolution order
On startup, TREK resolves the encryption key in this order:
ENCRYPTION_KEYenvironment variable — explicit, always takes priority. When set, the value is also written to./data/.encryption_keyso it survives container restarts if the env var is later removed../data/.encryption_keyfile — present on any install that has started at least once../data/.jwt_secretfile — one-time fallback for older installs that pre-date the dedicated encryption key. The value is immediately persisted to./data/.encryption_keyso future JWT rotations cannot break decryption.- Auto-generated — fresh install with none of the above. A random 32-byte hex key is generated and written to
./data/.encryption_key.
What happens if the key is lost
All encrypted settings (API keys, SMTP password, OIDC secret, MFA secrets, notification tokens, etc.) become unreadable — TREK cannot decrypt them. They must be re-entered manually after the key is restored or replaced. Unencrypted data (trips, places, users, etc.) is unaffected.
Backing up the key
Unless you set ENCRYPTION_KEY in the environment, your backup ZIP does include the encryption key: ./data/.encryption_key is bundled into every archive, manual and automatic, as a root-level .encryption_key entry, so a restore onto a different install can still decrypt the stored secrets. That makes the ZIP exactly as sensitive as the key itself — store and transfer it accordingly.
On installs that supply the key through the environment the file is not the source of truth, so no backup carries it. Keep it somewhere separate — for example, in a password manager or a secrets manager. See Backups.
To find your current key: check the ENCRYPTION_KEY environment variable or read ./data/.encryption_key.
Rotating the key
Use scripts/migrate-encryption.ts to re-encrypt the stored secrets listed below without downtime or manual re-entry.
Docker:
docker exec -it -w /app/server trek node --import tsx scripts/migrate-encryption.ts
Host (run from the server/ directory):
node --import tsx scripts/migrate-encryption.ts
The script:
- Prompts for the old and new encryption keys interactively (keys are never echoed to the terminal or written to shell history).
- Asks for confirmation before making any changes.
- Creates a timestamped backup of the database (e.g.
travel.db.backup-1713484800000) before modifying anything. - Re-encrypts all stored secrets across all tables:
app_settings:oidc_client_secret,smtp_pass,admin_webhook_url,admin_ntfy_token,maps_api_key,unsplash_api_key,amap_api_keyapp_settings['storage.backends']: thesecretAccessKeyof every S3 storage backendusers(per user):maps_api_key,unsplash_api_key,amap_api_key,openweather_api_key,immich_api_key,synology_password,synology_sid,synology_did,airtrail_api_key,mfa_secretsettings(per user):webhook_url,ntfy_token,mapbox_access_token,carto_api_key,llm_api_keydawarich_connections(per user):api_keyplugin_oauth_tokens:access_token,refresh_token(per plugin and user)plugins.configandplugin_user_config.config: every settings field a plugin's manifest markssecret, resolved per plugin and scope fromplugin_settings_fieldstrip_album_links:passphrasetrek_photos:passphrase
- Reports counts of migrated, already-migrated, skipped (empty), and errored values.
Not covered by the script: the document sync credentials (document_connections.secrets and trip_document_links.webhook_secret) and the instance-wide API key of the AI Parsing addon (addons.config). They stay encrypted under the old key and read back as empty afterwards. The AI Parsing key has to be entered again under Admin → Addons. A document sync binding fails with The credentials were refused. and cannot be repaired from the trip: the connection form only opens for a store the trip has not been connected to yet, and Disconnect removes the binding but keeps the stored connection. Removing the trip's row from document_connections takes its bindings with it and lets the trip owner connect the store again; the documents themselves stay in TREK and at the store. Rotate before trips are bound to a store where you can. See Document-Sync.
After a successful migration:
- Update
ENCRYPTION_KEYin your environment to the new value. - Restart TREK.
If any secrets could not be migrated, the script exits with a non-zero status and the original database backup is retained.
Upgrading from very old versions
Old installs may have used ./data/.jwt_secret as the encryption source (before a dedicated ENCRYPTION_KEY was introduced). The key resolution chain above handles this automatically on startup — the JWT secret is read, immediately written to ./data/.encryption_key, and JWT rotation is then safe without breaking decryption.