Djangocon EU: zero-migration encryption - Vjeran Grozdanic¶
(One of my summaries of the 2026 Djangocon EU in Athens).
Full title: zero-migration encryption: building drop-in encrypted field in Django.
He works at Sentry. Huge site with a Django backend and thousands requests per second.
He had to add a new table to store 3rd party API credentials. Oh: should this be encrypted? Yes. But: each team has its own way to encrypt data. And there were at least 10 encryption keys here and there (as environment variables). And tens of places where encryption/decryption happens.
So: better to build a generic solution. Or use an existing generic solution. And yes,
there are multiple libraries. EncryptedCharField looked nice. But the problem was
all the existing data in the various places. Sentry is not a site that you can shut down
for a while, so you have to do it with zero downtime. This means you can never change an
existing column type.
A solution could be to add a new encrypted field next to the existing one. Then fill it and backfill it and make sure no new data is written to the old field and then you can remove the old field. But that’s quite a job with all the different locations that had to be changed.
A Field class in Django has get_prep_value() and from_db_value(). Those are
called before storing data in the database and after grabbing it from the database. You
could create a new CharField-like field and start to encrypt values in
get_prep_value and decrypt the other way.
You’d have to be able to recognise the old un-encrypted values. A solution: prefix
encrypted values with enc:. Also key rotation can be handled this way, by including
that in the prefix (enc:key2:).
But there’s also a bjson field. They solved that by encrypting the json and writing a json to the database with the encrypted json in a field and also the encryption key info.
The code is in the sentry repo .
Unrelated photo explanation: a cat I encountered in Athens on an evening stroll in the neighbourhood behind the hotel.