Secrets management for application teams

The problem Keel solves

Most teams start with a .env file and a shared message thread. That works until someone leaves, a laptop is lost, or a value changes and half the team keeps running the old one. Secrets end up in repositories, screenshots, CI settings, and personal notes, with no record of who has what.

Keel replaces that sprawl with a single system of record. Each project holds its secrets per environment, every change is versioned, and access is decided by role rather than by who happened to receive a copy.

How secrets are stored

• Secret values are encrypted at rest with AES-256-GCM. Each value gets its own random nonce and an authentication tag, so tampering is detected on read.
• The encryption key is supplied by the server environment and is never written to the database.
• Values are decrypted only after the request passes project role and environment access checks.
• Revealing a value and exporting an environment are recorded in the audit log.

How teams use it

1. Create a project and choose who can access it.
2. Add secrets to the Development, Staging, and Production environments, or import an existing .env file.
3. Invite teammates with the role that fits: owner, admin, member, or viewer.
4. Change values when you need to. Earlier values stay available through version history.

What Keel does not do yet

Being clear about limits matters for a security product. Keel does not currently rotate secrets automatically, does not issue machine or API credentials separate from user accounts, and does not use an external KMS or HSM. The encryption key is held by the server environment.