Encryption and data boundaries
When configured and migrated, minddy encrypts workspace content and files before durable writes with authenticated server-side encryption.
What at-rest encryption protects
When configured and migrated, minddy encrypts workspace content and files before durable writes with authenticated server-side encryption. Project, user and system data keys are versioned and wrapped by a dedicated root outside PostgreSQL. A database-only extraction cannot read protected content without its keys. The application must decrypt for authorized access, search and unattended AI work. A compromised runtime or access to both configuration keys and data crosses that boundary; this is not end-to-end secrecy from the operator.
Identify readable or exported data
Auth keeps login email as account identity. Routing IDs, project/issue keys, states, priorities, timestamps and other allowed metadata remain queryable. Publicly published content is intentionally readable to its audience. Exports, downloaded files, browser-visible content and information sent to external AI, email, Git or MCP providers require their own handling. A configured flag does not prove historical copies, logs or provider-retained data were converted or retired. Never claim Cloud production encryption status from repository source alone.
Preserve keys with a coordinated recovery plan
Keep MINDDY_DATA_ROOT_KEY protected outside the database and retain recovery copies for current and historical backups. Recover database, Storage bytes and matching configuration as one consistent set. Encrypt the outer backup if it contains both data and keys. Changing the root without rewrapping keys makes existing content unreadable; turning content encryption off does not convert ciphertext back to plaintext. Rehearse recovery before activating encryption on existing data and verify actual decrypted content and downloaded bytes.