Secrets belong to the runtime,
not the repository.

Status: milestone 2

Core, encrypted vault, CLI and read-only SDKs for Python, JavaScript/TypeScript, Rust, Java, .NET, Go, C, C++ and PHP. Local-first and usable today on Windows, macOS and Linux. 0.1.3 is on PyPI, crates.io, Maven Central, NuGet, Packagist, npm and pkg.go.dev, and on the GitHub release. The authenticated local broker and remote providers are on the roadmap. Not yet audited; do not treat it as a production secret store.

Why

We give coding agents access to repositories, terminals and build pipelines while still distributing credentials through plaintext files that sit in the working tree, get indexed, get pasted into prompts and get committed. SourceOrrery takes a different line.

No plaintext at rest

Every value is encrypted (XChaCha20-Poly1305) in a single SQLite file. The vault key is protected by your OS credential store and/or an Argon2id passphrase.

References, not values

sourceorrery://development/database-password is safe to commit, log and paste. It resolves only inside an authorised runtime.

A manifest that cannot leak

sourceorrery.toml declares the secrets a project needs. A value = ... key is a parse error.

Metadata by default

list, versions, get and audit never print a value. Disclosure is a deliberate get --reveal.

Versioned and recoverable

Every set creates an immutable version. Deletes are soft, recoverable and audited. Expiry and activation times are enforced, not advisory.

One implementation

The Rust core owns every semantic. Backends and language bindings pass the conformance suite or they are not SourceOrrery.

What SourceOrrery does and does not protect

Three different guarantees, kept separate on purpose. The threat model spells out each one.

Guarantee	Today
At-rest protection — no plaintext secrets on disk, in the repo or in agent context	Yes
Access control — which identities may retrieve which secret	Local only: whoever can unlock the vault
Agent isolation — an untrusted agent running as your user cannot impersonate your application	No. Requires the authenticated broker and OS isolation (milestone 3)

Removing .env closes the accidental-exposure routes. It does not stop code running with your privileges from calling the same API you can. SourceOrrery says so rather than promising otherwise.

Quick start

# 1. Create a vault (key protected by the OS credential store when available)
sourceorrery vault create development

# 2. Store a secret — interactively, from stdin or a file; never as an argument
sourceorrery secret set database-password --vault development

# 3. Inspect without revealing
sourceorrery secret list --vault development
sourceorrery secret get database-password --vault development

# 4. Declare what your project needs and run it with secrets injected
sourceorrery init
sourceorrery check
sourceorrery run -- npm start      # DATABASE_PASSWORD is set in the child only

The getting started page walks through each step, starting with installing the release.

Read on

Getting startedInstall the release, create a vault, store a secret, run your application.

SDKsRead secrets from Python, JavaScript/TypeScript, Rust, Java, .NET, Go, C, C++ and PHP.

Headless: WSL, Docker, CIUnlock a vault where there is no OS credential store or no terminal.

CLI referenceEvery command, option and environment variable.

Threat modelThe three guarantees, the adversaries, the controls and the known gaps.

ArchitectureCrates, domain model, cryptography, storage and the integration surface.

RoadmapFrom the local CLI to SDKs, the broker and enterprise providers.