Declarative secrets manager for development, CI, and multi-backend stores
Define secrets as a contract and fetch values from external providers using a TOML spec, idempotent generators, and SDKs that work across projects. SecretSpec, by Domen Kožar, targets developers and DevOps teams on desktop and CI platforms. The tool includes a CLI for lifecycle commands, GitHub Actions masking, and SDK bindings for Rust, Python, Go, Node.js, and Ruby. It fits teams that want reproducible local environments without plaintext .env files.
How SecretSpec replaces fragile .env workflows
SecretSpec uses a secretspec.toml file to declare what an application needs while leaving actual values in external stores, which separates declaration from storage. The configuration file format is TOML, and the tool supports system keyrings and third-party providers such as 1Password and Vault. That contract-first approach removes plaintext environment files from repositories by design, shifting secret values to secure backends instead of storing them alongside code.
Does it affect developer workflows and tooling?
The tool provides a CLI for checking and running secret resolution and offers native integration with the devenv.sh environment tool, so it plugs into existing development flows. In addition, SecretSpec exposes SDKs for more than a dozen languages, which lets applications resolve secrets at runtime rather than relying on generated files. Being available via WinGet on Windows and as packages on other platforms helps installability across desktops.
Is it safe enough for CI and shared systems?
SecretSpec includes a dedicated GitHub Action that resolves and masks secrets in CI, and it supports secure backends like Vault and keyrings. The action masks outputs so secrets do not appear in logs, and the CLI model keeps secret values in external providers rather than embedding them in the build. These behaviors reduce the common leakage vectors associated with plaintext .env workflows.
Who gains most and what level of skill is required?
The primary audience comprises developers and DevOps engineers who accept configuration files and external secrets stores as part of their workflow. Idempotent generation of passwords and keys handles onboarding friction, but using multiple providers and the TOML specification requires familiarity with config-driven tooling and external secret backends. Teams already using Nix or the devenv.sh tool get tighter integration out of the box.
Practical for teams that adopt config-driven secret management, with a config learning curve
SecretSpec suits developers and operations teams who want contract-based secrets and CI masking, backed by multi-language SDKs and support for standard providers. The single notable trade-off is the operational overhead of managing external providers and learning the TOML declaration model, which makes it less appropriate for teams that prefer minimal configuration or single-file secret handling.
