Encryption keys now live in Scaleway Key Manager
Our apps no longer read their keys as plaintext from the pod environment. They unwrap them at boot from Scaleway Key Manager in Paris, so the data and the keys that open it have different custodians.
Kumiko apps encrypt personal data field by field, with a separate key per person. That is what makes crypto-shredding work: delete a person, destroy their key, and their data is unreadable even in backups.
The promise depends on where the key above those keys is kept. Until now it sat as an environment variable in the same cluster as the encrypted data. Anyone who compromised the cluster would have had both.
As of today all five production apps unwrap their three keys at boot from Scaleway Key Manager in Paris. The cluster holds only a ciphertext that is useless without the key manager, and every access shows up in the key manager’s audit log. The encrypted data stays at Hetzner, so neither provider holds a complete set on its own.
One honest note, because this comes up in security questionnaires: Scaleway’s Key Manager documentation mentions neither HSM nor FIPS. What you gain here is separated custody, not a hardware security guarantee.
Self-hosters get the same path from the framework. Mark a key field as a KMS slot in your env schema, have your deployment supply the ciphertext, and the app unwraps it at boot in a single call. The guide walks through the steps, including the traps we hit on the way.
Related