Local keys

The local ingredient stores encryption and signing keys unencrypted in .ramenv.keys at the workspace root. It is the default and requires no cloud identity.

Initialize a local workspace

ramenv init
# Equivalent for a new single-repository workspace:
ramenv init --ingredient local

For a monorepo without a root vault, use ramenv init workspace --ingredient local, then initialize each service separately. See workspaces.

Keep keys out of Git

Initialization adds .ramenv.keys and .env to .gitignore. Check that neither file was already tracked:

git ls-files -- .ramenv.keys .env

If this prints either path, the file is already tracked. Untrack it and investigate its history. Removing a file from the current commit does not erase older copies. Treat exposed keys and credentials as compromised.

Restrict the key file’s access with your operating system’s permissions. For example, on a POSIX filesystem:

chmod 600 .ramenv.keys

This limits ordinary file access; it does not isolate secrets from privileged users or an agent running as your user.

Share with collaborators

Commit the workspace metadata and reviewed vault. Send collaborators the matching key file through a secure channel so they can read encrypted values and verify the vault.

Services within a workspace share encryption keys per environment. Each registered vault has a separate signing key. Avoid mixing key files from different workspaces or replacing a current key file with an unrelated backup.

To manage key access through cloud identities, choose a cloud ingredient for a new workspace. Re-running init does not migrate an existing workspace.

Back up and rotate

Back up keys securely with the vault versions they decrypt. Losing the corresponding encryption key makes encrypted values unrecoverable. Rotation changes the key required by current encrypted values, so keep recovery material consistent with the vault history you intend to restore.

ramenv rotate production

Rotation re-encrypts values across registered workspace vaults containing that environment and preserves plaintext values. In multi-vault workspaces it prompts for confirmation. Use --yes to confirm the workspace-wide change without a prompt.

Local keys and the vault in the same readable checkout do not protect secrets from a process that can read both. Review the security boundaries and deployment checklist.