Projects and environments

kyvlt.sh files secrets in three levels.

• Organisation — everyone you work with, and everything below.
• Project — one system: an application, a service, a repository.
• Environment — one deployment of that project. Call them what you like.

Keys live in an environment. DATABASE_URL in production and DATABASE_URL in staging are two separate secrets that share a name, so changing one does not touch the other.

Values are versioned

Setting a key keeps the old value as a version. The history of a key shows the version number, when it changed and who changed it — never the value, until you ask for one.

Restoring an older version writes a new version holding that value. Nothing is rewound, so the history stays a record of what happened.

Copying between environments

Keys can be copied from one environment to another. Ask for a preview first and you see exactly which keys would land before any of them do. Keys that already exist in the destination are left alone unless you choose to overwrite them.

Protected environments

An environment can be marked Protected. The app then asks you to confirm reveals and deletions there that it performs without ceremony elsewhere.

It changes no permission: what you may do is the same either way, and only the friction differs.

Who can see what

Members hold one of four roles: Owner, Admin, Developer or Viewer. A Viewer sees that a key exists and never what it holds.

The API decides every permission and refuses again on every call. Screens hide what you may not do rather than letting you find out by failing. Every reveal is recorded in the audit log before the value is handed over.