Secrets belong to the runtime,
not the repository.

The local vault and runtime workflow. Explore the architecture for implementation details and future boundaries.

SourceOrrery 0.1.4

An encrypted local vault, CLI, interactive vault manager and read-only SDKs for Windows, macOS and Linux. This build includes a .env importer and integrations for AI coding agents. See what is included in 0.1.4.

From a credential to a reference

SourceOrrery is a local-first secrets platform written in Rust. Use the CLI to manage credentials and a value-free project manifest to declare what your app needs. Read them through an SDK, or inject them into a child process at launch.

Encrypted local storage

Secret values are encrypted with XChaCha20-Poly1305 in a SQLite vault. Protect the vault key with your OS credential store, a passphrase, or both.

References in your repository

Declare which secrets your project needs in its manifest. Inline value fields are rejected; keep names and other metadata free of secrets too.

Metadata by default

Inspect names, versions and status without printing secret values. Revealing a value requires an explicit get --reveal.

A complete secret lifecycle

Version values, enforce activation and expiry, recover soft-deleted secrets, and inspect a tamper-evident audit log.

Start with the CLI

Install SourceOrrery, then run these commands in your project directory. The secret prompt is hidden; values are never command-line arguments.

Create a development vault

sourceorrery vault create development
sourceorrery secret set database-password --vault development
sourceorrery secret list --vault development

Declare the secret in a project manifest. The vault and secret name resolve to sourceorrery://development/database-password:

sourceorrery.toml

[project]
name = "my-app"
vault = "development"

[secrets.database-password]
env = "DATABASE_PASSWORD"

Check the manifest and launch your app

sourceorrery check
sourceorrery run -- npm start

npm start receives DATABASE_PASSWORD; your parent shell is unchanged. The child process can read and disclose its environment, so run code you trust. The getting started guide covers unlocking, verification and working without an OS credential store.

Use your language

All SDKs are read-only and share the Rust core’s semantics. Manage vaults and secret versions with the CLI, then read values through a scoped accessor in your application.

• PythonSDK guidePyPI
• JavaScript / TypeScriptSDK guidenpm
• RustSDK guidecrates.io
• JavaSDK guideMaven Central
• .NETSDK guideNuGet
• GoSDK guidepkg.go.dev
• CSDK guideRelease archives
• C++SDK guideRelease archives
• PHPSDK guidePackagist

Know the security boundary

Local protection, with clear limits

SourceOrrery has not had an independent security audit and should not be treated as a production secret store. Any process running with your privileges that can unlock the vault can read it. The authenticated broker and per-runtime access controls are planned, not available today.

Protection	Available today
Secret values encrypted in the vault	Yes. Names, tags and other metadata remain visible.
References instead of credentials in project files	Yes, when you keep secret values out of names, comments and metadata.
Version policy and tamper-evident audit records	Yes. A full rollback of the vault needs an external checkpoint to detect.
Isolation from an agent running as your user	No. Local unlock access is the current boundary.

Read the threat model before choosing where to use SourceOrrery. It distinguishes vault protection from secrets copied into application memory, logs, process environments or other files.

How it fits together

The CLI and SDKs use the same Rust implementation. A manifest stores references, the local vault stores encrypted values, and the application chooses when to resolve a secret.

Find your next step

Getting startedInstall, create a vault and run your first application.AI coding agentsSet up SourceOrrery and migrate a project with value-safe agent skills.Docker, WSL and CIUnlock a vault in a headless environment.CLI referenceLook up commands, flags, environment variables and exit codes.Supply chainCheck packages, release checksums and publishing provenance.Build from sourceBuild the CLI, native library and language bindings.