Skip to the article

Workspace encryption

Check encryption behavior for your release and preserve credential and workspace recovery keys.

Choose the new-install setting

The --encryption installer and bootstrap options in this article ship with this release's tooling. The v0.11.0 installer and bootstrap do not accept them. Its application runtime recognizes MINDDY_CONTENT_ENCRYPTION_ENABLED; the reference Compose service loads the protected file through env_file. An explicit flag change therefore requires recreating the application service with the same environment and checking the schema and actual behavior. Do not treat a generated MINDDY_DATA_ROOT_KEY as proof that workspace content is encrypted. Use matching, explicitly verified tooling and configuration for the selected release before onboarding users or changing an existing instance.

New local and server installers enable workspace encryption by default and generate a dedicated MINDDY_DATA_ROOT_KEY. For a new server, pass --encryption enabled or --encryption disabled explicitly if needed. Both choices preserve credential encryption and generate the independent root; the opt-out concerns workspace content. For the local desktop path, prepare the selected configuration before opening the clone with the command below. The root is a 32-byte random value encoded as exactly 64 hexadecimal characters, kept outside PostgreSQL.

Bash
pnpm bootstrap:supabase -- --minimal --app-url http://localhost:6463 --encryption enabled
Dedicated root outside PostgreSQL
Wrapped project, user and system keys
Authorized server decryption
Database + Storage + matching keys restore
Restoring encrypted content requires matching data and keys, including the root kept outside the database.

Handle existing data and reruns

Existing configuration without the flag stays disabled until you change it deliberately. Reruns retain the saved flag and root; a conflicting explicit installer choice fails. Never generate a replacement to repair a missing key on an enabled instance: recover the original key. Apply the required schema and verification before importing data. Bounded maintenance advances legacy conversion and rotation; setting the flag does not certify complete conversion of old content or retained copies. Turning the flag off does not decrypt protected data or authorize new plaintext writes to protected scopes.

Keep a recoverable encryption set

The server decrypts content for authorized users and AI processing, so this is at-rest encryption rather than end-to-end secrecy from the application operator. Login emails and routing metadata remain readable, and external providers and exports require separate protection. Preserve current and historical root keys for retained backups. Encrypt and restrict access to a full backup containing both configuration and data. Rehearse a database-plus-Storage restore with matching keys. Changing the root needs a guarded offline rewrap while applications are stopped; a casual environment replacement makes protected content unreadable.

Related articles