Flarite Docs

Token Encryption

Every API token you add to Flarite is encrypted with AES-256-GCM before being written to the database.

Encryption algorithm

Flarite uses AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode). AES-GCM provides both encryption and authentication — meaning a tampered ciphertext cannot be decrypted without detection.

How it works

  1. When you submit a token, it is received by the Cloudflare Worker over TLS.
  2. A random 96-bit initialization vector (IV) is generated per encryption operation.
  3. The token is encrypted using the IV + the ENCRYPTION_KEY Worker Secret.
  4. The IV and ciphertext are concatenated and stored in the D1 database as a hex string.
  5. When a tool needs your token, the Worker retrieves the ciphertext, decrypts it in memory, uses it for the API call, and discards the plaintext immediately.
Storage format: [12-byte IV (hex)] + [ciphertext (hex)]
Example:         a3f2...9d1c + 7b8e...f402

At no point is the plaintext token written to disk, logs, or any external system.

The encryption key

The ENCRYPTION_KEY is a Cloudflare Worker Secret — a special encrypted environment variable that is:

  • Never visible in the Cloudflare dashboard after being set
  • Not accessible via the Worker's source code or logs
  • Only available to the running Worker process at runtime
  • Never stored in version control or configuration files
⚠️
ImportantIf the ENCRYPTION_KEY is rotated, all previously stored encrypted tokens become unreadable. Only rotate the key if you intend to ask all users to re-add their credentials.

What this means for you

  • Even if someone gained read access to the D1 database, they would only see ciphertext — useless without the key.
  • Flarite staff cannot decrypt your tokens — the key is only held by the Cloudflare Worker runtime.
  • Deleting a credential from Flarite permanently removes the encrypted record from the database.