Skip to main content
Tilde uses envelope encryption. Two kinds of key are involved:
  • The envelope encryption key (EEK) is the top-level key. You control it, and Tilde never stores it.
  • A data encryption key (DEK) encrypts your secrets. Tilde generates it, encrypts it with the EEK, and stores only that encrypted copy in PostgreSQL.
Tilde uses the DEK to encrypt connection secrets, OAuth tokens, webhook signing keys, and every other secret it stores. Tilde issues a DEK for each registry. Envelope encryption in Tilde: the envelope encryption key from your key provider unwraps the data encryption key, which encrypts each secret with AES-256-GCM before it is stored in PostgreSQL
Click to zoom
A database dump alone is useless to an attacker. Without your EEK, the DEK cannot be unwrapped, and without the DEK, no secret can be read.

​
Choose an envelope key provider

Tilde generates and manages DEKs for you. You configure the EEK when the gateway starts.
Create a KMS key and give the gateway’s role permission to use it. Tilde asks KMS to generate the DEK and to unwrap it at startup, so the EEK never leaves the KMS hardware security modules.The gateway needs only two permissions on the key: kms:GenerateDataKey and kms:Decrypt. Tilde binds every KMS call to an encryption context, and verifies that KMS used the key you configured.
We can add other key providers to meet your requirements, such as HashiCorp Vault.
Use a user-provided key for local development and automated tests. Use AWS KMS, or another managed provider, for every cloud environment, including development and production. Tilde supports envelope key rotation, and we advise rotating your EEK regularly.

​
How secrets are encrypted

Context binding stops an attacker who can write to the database from moving a ciphertext to another record or field. A secret copied into the wrong row fails authentication and is rejected.

​
What is encrypted and what is hashed

Tilde encrypts values it must read back, and hashes values it only needs to verify. Tilde shows a hashed credential once, when you create it. It cannot show it again.

​
How secrets are handled in memory

Encryption at rest protects the database. Tilde also limits how long a decrypted secret exists in the gateway’s memory, and what can read it there.
  • Short-lived. Tilde holds a decrypted credential in memory only briefly, and never longer than the credential itself is valid.
  • Wiped, not only freed. Tilde overwrites keys and decrypted values the moment it releases them. Secrets do not linger in freed memory, where a memory disclosure bug, core dump, or swap file could expose them.
  • Never logged. Secrets are carried in types that redact themselves in debug output and refuse serialization. A stray log line or error report cannot contain a secret.
  • Never traced. Credential headers are marked sensitive, and Tilde’s instrumentation does not capture request bodies or authorization headers.
  • Constant-time checks. Tilde verifies signatures without leaking timing information.
  • Memory safe. The gateway is written in Rust, which rules out the buffer overflows and use-after-free bugs behind most memory disclosure attacks.
Agents have no access to any of this data. They run in separate containers, across a network boundary, and they receive only short-lived invocation tokens. See IAM.

​
Standards alignment

Tilde’s encryption follows published guidance for cryptographic storage.