Encryption Troubleshooting
Diagnosing and fixing problems with encrypted database fields. For how encryption works, see Database Field Encryption.
Quick checks
Count encrypted vs. plaintext rows (plaintext should be 0 after the migration):
Common issues
”DB_ENCRYPTION_KEY Field required” at startup
The key is missing. It is required with no default, and a missing or invalid key stops the backend from starting rather than silently disabling encryption. Generate one, set it in the environment (or the Kubernetes secret / GCP Secret Manager in deployed environments), and restart:
DecryptionError / “Invalid encrypted data or wrong encryption key”
Reads fail loudly when a value cannot be decrypted. Two causes:
- The value is still plaintext because the data migration never ran — run
alembic upgrade head, or re-save the affected records to encrypt them. - The value was encrypted with a different key. Confirm the same key across all instances
(
echo $DB_ENCRYPTION_KEY | md5sum) and restore the original key from backup if it was changed.
Endpoint or model calls failing on the stored token
The token is not decrypting. Confirm the key is correct, then check backend logs:
Re-saving the record re-encrypts it with the current key. In application code the value is already
decrypted by the ORM (is_encrypted(endpoint.auth_token) should be False).
Migration failed partway through
alembic upgrade head is idempotent — already-encrypted values are skipped — so re-run it. If it
keeps failing, check the database connection and statement timeout.
Debug script
Reports how many rows are encrypted per field:
Note: reading through the ORM decrypts values, so is_encrypted on an ORM attribute reflects
decrypted plaintext, not the stored ciphertext. Use the SQL checks above to inspect what is
actually stored.
Getting help
Collect recent encryption-related logs and open a GitHub issue with the encryption label: