Locket
Locket manages development secrets through an encrypted local vault and project command policies. The project records variable names and rules in locket.toml, while values stay in the vault. A policy identifies the command to run and the variables it may receive. This gives a team a shared configuration contract without putting everyone's credentials in the repository. Profiles separate development contexts, and directory scopes can add package-specific requirements in a monorepo. Locket supplies the selected values to a child process for that invocation, so developers can run familiar application commands through the CLI.
From a local env file to a command policy
Move configuration and secret values into their respective project and vault records.
Initialize the project
Create the project and its development profile. Initialization prepares the vault, writes project configuration, and maintains a names-only .env.example contract.
Add the required values
Import an existing env file or write individual values through stdin. Inspect the import summary and check whether the original plaintext file was retained.
Define the command policy
Save the command arguments and name its required or optional variables. Marking a variable required makes a missing value a policy error before execution.
Inspect and run
Review the metadata-only injection plan, then run the saved policy. Locket prepares the child process environment without exporting those vault values into the parent shell.
Build the CLI from source
The documented installation uses a checkout of the GitHub repository and its pinned Rust toolchain. Run this from the Locket repository root. Then change to the application directory before initializing your project.
cargo install --path crates/locket-cliRun a development server with its database variable
This example assumes the application already has an npm dev script and a local .env containing DATABASE_URL. The saved dev policy runs that script. The inspection command shows which variables the policy will receive without displaying their values.
locket init --name my-app --profile dev
locket import .env
locket policy add dev -- npm run dev
locket policy require dev DATABASE_URL
locket env inspect --policy dev
locket run devShare names and rules across a monorepo
A shared dev command can have different requirements in apps/api and apps/web. Directory scopes name the variables for the active package; the deepest matching scope applies. This keeps package requirements in project configuration while values remain local. Secret access rules can further restrict the command identity, arguments, and project-relative directory. Inspect the policy from the package directory to see the effective scope before running it.
Keep the development boundary clear
Use platform-native secret stores for CI and production, as the README recommends. A local profile named staging is still part of a development workflow.
Import is a migration step to review. The CLI can remove an imported .env after an explicit deletion confirmation; noninteractive import retains it. Check the result before deciding how to handle the original file. Default metadata views help inspect configuration without revealing values; use reveal commands deliberately.
Explore the other libraries
Browse the DoubleSharp catalog for other tools used in application development and testing.