Skip to content
SourceOrrery0.3.0

Open source · Rust-native · Local-first

Secrets belong to the runtime,
not the repository.

Store development credentials in an encrypted local vault. Commit references, give your application the values it needs, and leave plaintext .env files behind.

Why SourceOrrery?

Get startedExplore the SDKs
Status
0.3.0 · local-first
Licence
MIT or Apache-2.0
Source
github.com/Netizine/sourceorrery
The SourceOrrery emblem, an orrery between angle bracketsThe SourceOrrery emblem, an orrery between angle brackets
SourceOrrery 0.3.0 architecture The CLI administers secrets, application SDKs read them, and a value-free manifest declares references. All use a local schema 5 vault and the shared Rust implementation. The vault key opens through the OS credential store or a recovery key; the optional view check is for interactive viewing. The local vault holds authenticated catalog and audit state, local ciphertext and sealed provider credentials. Routed dispatches each secret to that file, AWS Secrets Manager, Azure Key Vault or HashiCorp Vault KV v2. Remote providers enforce their own identity and policy. There is no broker or same-user isolation in 0.3.0. SOURCEORRERY / SYSTEM DESIGN SourceOrrery 0.3.0 A local vault. Per-secret storage. One Rust implementation. CLI & terminal screens Create, change and audit secrets Browser displays metadata only run → child environment Read-only application SDKs Python · JavaScript/TypeScript · Rust Java · .NET · Go · C · C++ · PHP Values, properties and projects Project manifest sourceorrery.toml Local vault and secret references No values or provider credentials Open locally, then resolve the requested secret Local vault + shared Rust implementation Core lifecycle and policy contracts · storage integrity · Routed per-secret dispatch Unlock & interactive checks This-machine key → OS credential store Recovery key → HKDF key wrap Both open the same vault data key Optional password + authenticator view check For viewing; SDKs, run, check and init bypass it Authenticated local vault · schema 5 Local values: XChaCha20-Poly1305 ciphertext Catalog: secret → file or provider connection Sealed credentials, project paths and names Authenticated settings, wrap inventory and audit Application C ABI 2 · contract 2 PER-SECRET STORAGE Local encrypted values Inside the same vault file Versioned and policy checked Audited in the local vault AWS Secrets Manager Values remain in AWS Properties are per secret AWS identity and policy Azure Key Vault Values remain in Azure Properties are per version Azure identity and policy HashiCorp Vault KV v2 Values remain in Vault Properties are per version Vault token and policy Clear boundaries The view check is not encryption or application authorisation. Remote reads also pass provider policy. No daemon, local IPC service or same-user isolation is included in 0.3.0. SOURCEORRERY.AI / ARCHITECTURE Export/import moves local vault data, not remote values.
The 0.3.0 local vault, provider storage and runtime workflow. Explore the architecture for implementation details and future boundaries.

From a credential to a reference

Section titled “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. This machine’s key lives in your OS credential store; a recovery key opens the vault anywhere else.

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.

Setup options

Section titled “Setup options”

Option 1: Set up with the CLI

Section titled “Option 1: Set up 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 setup                     # the vault, its recovery key, its checks and storage
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.

Option 2: Set up with an AI coding agent

Section titled “Option 2: Set up with an AI coding agent”
Terminal window
sourceorrery init --integration all

Use your existing coding agent and ask: “Set up SourceOrrery for this project without showing secret values.” Replace all with your agent’s name to install only its skills. The agent handles the manifest, code and launch commands; you create vaults and enter values privately. The agent setup guide also covers updating skills from the repository independently of the CLI.

Use your language

Section titled “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.

Know the security boundary

Section titled “Know the security boundary”
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

Section titled “How it fits together”

The CLI and SDKs use the same Rust implementation. A manifest stores references. The local vault stores encrypted local values and the catalog of provider-backed secrets; the application chooses when to resolve them.

Find your next step

Section titled “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.