Encrypt application data without your app ever holding a key. The transit engine encrypts and decrypts on demand, and rotates keys without re-encrypting your data.
Why: apps that encrypt data usually have to store and protect the key themselves — the hard part. The transit engine flips this: your app sends plaintext, Vault returns ciphertext, and the key never leaves Vault. Vault does not store your data; it only does the crypto. This is "encryption as a service".
app ──plaintext──▶ Vault (transit) ──ciphertext──▶ app stores it in its DB
app ──ciphertext─▶ Vault (transit) ──plaintext──▶ app uses it
(the key stays inside Vault — the app never sees or stores it)Why: enable the transit engine and create a named encryption key. The key lives in Vault and is referenced by name — your app never downloads it. You can have many keys for different data classes (user PII, payment data), each managed independently.
vault secrets enable transitCreate a named key
vault write -f transit/keys/ordersWhy: to encrypt, send base64-encoded plaintext to the key's encrypt endpoint; Vault returns ciphertext that starts with "vault:v1:" (the v1 marks the key version). Decrypt reverses it. Your app stores only the ciphertext; the key never leaves Vault.
Encrypt (plaintext must be base64-encoded)
vault write transit/encrypt/orders \
plaintext=$(echo -n "order #1234" | base64)Decrypt the returned ciphertext
vault write transit/decrypt/orders \
ciphertext="vault:v1:...."Why: keys should rotate, but re-encrypting all stored data is painful. Transit versions keys: rotate creates a new version for future encryption while old ciphertext (tagged v1, v2…) still decrypts. rewrap upgrades ciphertext to the latest key version WITHOUT exposing the plaintext — so you rotate keys with zero plaintext handling.
Create a new key version (future encryptions use it)
vault write -f transit/keys/orders/rotateUpgrade old ciphertext to the new version without decrypting it
vault write transit/rewrap/orders ciphertext="vault:v1:...."