SecretSpec | Blog

Where .env Went Wrong

Thu, 30 Jul 2026 00:00:00 GMT

.env is one of software’s most successful accidents.

It starts as a shortcut for three export commands. Then it becomes the project’s configuration schema, secret store, environment model, onboarding guide, CI interface, and deployment format.

Environment variables do one job well: deliver strings to a process. .env turned that delivery mechanism into a source of truth.

A convenience became architecture. That is where .env went wrong.

Environment variables only deliver values

Environment variables solve a small problem: getting values into a running process. The application can read DATABASE_URL without knowing whether a developer, CI system, or secrets manager supplied it.

A .env file makes those values easy to save and reload. That is useful. But teams also use the file to describe what the application needs. KEY=value cannot say whether a value is required, secret, safe to commit, available only in production, or restricted to one service.

Those requirements outlive any process and any developer laptop. They belong in a durable project declaration. .env stores values for delivery; it cannot define the application’s secret model.

A string is not a schema

Consider a typical example file:

.env.example

DATABASE_URL=
REDIS_URL=redis://localhost:6379
STRIPE_API_KEY=
DEBUG=false

The file raises more questions than it answers. Does an empty value mean required or optional? Is REDIS_URL a development default? Is STRIPE_API_KEY production-only? Is DEBUG a boolean?

Dotenv cannot encode those answers. Node.js documents that every value becomes a string. A dotenv issue about booleans, opened in 2015, still collects reactions from developers surprised that "false" is truthy.

Teams put the missing information elsewhere: validation code, a README, .env.example, or a teammate’s memory. These sources drift.

The file also makes DEBUG and STRIPE_API_KEY look equivalent. One is an ordinary setting that belongs in Git. The other grants authority and needs access control and rotation. Mixing them makes the whole file sensitive.

Without an explicit declaration, missing values fail late: the application discovers them only when code tries to use them.

Then the file starts to multiply

A new requirement usually creates another file:

.env
.env.local
.env.development
.env.development.local
.env.test
.env.production

The filenames become an environment model. Suffixes define scope, load order defines inheritance, and copying a file becomes deployment.

This reverses the Twelve-Factor App’s guidance. Its point was that environment variables should be independent controls because named environments become brittle as deployments multiply. .env.production recreates that grouping in a filename.

Now every new value must be added to .env.example, documented in a README, validated in code, and copied into the right real files. Miss one and the environments drift.

There is no `.env` spec

.env looks standardized, but every parser defines its own format. Node.js documents the lack of a formal specification, as does python-dotenv. Each loader makes its own choices.

python-dotenv expands ${NAME} but not $NAME. Node dotenv delegates variable expansion to another tool. Docker Compose supports its own shell-style operators. Vite even supports references in reverse order, then warns that the same expression will not work in a shell or Docker Compose.

Comments and quotes differ too. Node dotenv changed the meaning of # in unquoted values in version 15 as a breaking change. One devenv user found that quotes became part of an exported key.

Which value wins?

Parsers also disagree about precedence. Node dotenv normally lets the first file win. Docker Compose lets the last env_file win, then lets the environment section override that. Vite gives an existing process variable priority over its files.

Docker Compose gives two similar names different behavior. env_file: supplies variables to a container but does not use them to interpolate compose.yaml. docker compose --env-file does affect interpolation. In an issue closed as working as designed, a maintainer described the option’s name as unfortunately chosen.

Who loaded `.env` first?

Precedence also depends on timing. Node dotenv’s ES module guidance needs special handling when imported modules read the environment during initialization. Vite warns that Bun’s automatic .env loading can interfere with Vite’s own loading order. VITE_* values are replaced at build time and become part of the client bundle.

The same line can become a runtime secret, a build-time constant, or a public browser value. The loader decides based on timing and context.

At that point .env behaves like a small program, with control flow spread across filenames, flags, working directories, parent processes, and library versions.

An ignored file is still a file

The dotenv project says not to commit .env. .gitignore prevents one accident. It does not add encryption, access control, auditing, or revocation.

The file can still end up in editor backups, chat messages, archives, support bundles, container build contexts, and old laptops. A devenv integration was reported to copy .env contents into the Nix store, where paths are not confidential. When a developer leaves, there is no file access to revoke. Each credential they received is a separate copy.

Even a secret stored in 1Password, Vault, a cloud secret manager, or a system keyring must be copied into plaintext before a dotenv-based application can use it. The local copy has fewer controls than the original.

Environment-variable delivery has limits too. Docker mounts managed secrets as files because environment variables can leak between containers. A process also gets one global map, so a frontend build, worker, migration, and web service often receive the same secrets even when each needs only a few. Dotenv has no way to express that scope.

Let `.env` become small again

The useful part of .env is the short path from “this application needs a value” to “the application can run.”

Keep it as an adapter for tools that expect KEY=value, or use it for ordinary local settings. Do not make it define the project’s requirements, store durable copies of secrets, encode environments in filenames, or decide which services receive which values.

A durable design separates three jobs:

a committed declaration says which secrets the application needs;
protected storage controls who can read their values;
explicit delivery gives each process only the values it needs.

Each piece can then change independently. A team can change storage without rewriting the application, validate requirements before startup, and limit each component to its own secrets.

How SecretSpec applies this

SecretSpec puts the declaration in a file that is safe to commit:

secretspec.toml

[project]
name = "payments"
revision = "1.0"

[profiles.default]
DATABASE_URL = { description = "Postgres connection string" }
REDIS_URL = { description = "Redis connection string", required = false }
STRIPE_API_KEY = { description = "Stripe API key" }

[profiles.development]
REDIS_URL = { default = "redis://localhost:6379" }

This file records requirements, defaults, and descriptions without containing secret values. Providers choose where values live, and profiles describe real differences in requirements.

Existing programs can adopt SecretSpec without code changes:

secretspec run -- ./server

This command injects resolved secrets into the child process environment. It is useful during migration, while the preferred integration is a SecretSpec SDK.

With an SDK, the application resolves its declaration directly. This removes the environment-variable handoff used by secretspec run. Values stored in a keyring, password manager, or Vault never enter the global process environment. Applications that require a file can receive a temporary file instead. Scopes (0.17+) let each component resolve only the secrets it declares.

Migration can be gradual. SecretSpec initializes a declaration from an existing file:

secretspec init --from dotenv:.env

This copies names without copying values. The current file can remain a provider during the transition:

secretspec check --provider dotenv:.env
secretspec run --provider dotenv:.env -- ./server

Values can then move to a system keyring, password manager, Vault, or another provider without changing the names the application reads.

.env can remain for ordinary local settings. Existing applications can keep environment-variable delivery while they migrate. Applications using an SDK or file-based delivery can remove secrets from their process environments.

SecretSpec aims to eliminate environment variables for secrets altogether.

SecretSpec 0.17: Scopes, secrets caching, SOPS, age, and systemd credentials

Mon, 27 Jul 2026 00:00:00 GMT

SecretSpec 0.17 ships:

Scopes: let each service or task resolve only its declared subset of a profile.
Secrets caching: cache a slow fallback route in a local secret store with bounded freshness and explicit invalidation.
Cross-secret validation: declare alternative or mutually exclusive credentials instead of marking every value independently required or optional.
GitHub and Forgejo Actions: resolve a profile in one workflow step and expose its secrets to the steps that follow.
New providers: now with 20 providers, use SOPS, age, KeePass KDBX, OpenBao, Scaleway Secret Manager, and systemd credentials through the same SecretSpec interface, with JWT/OIDC authentication for Vault and OpenBao.

Scopes

A profile describes how secrets resolve for an environment. A scope now describes which of those secrets one consumer may receive:

secretspec.toml

[profiles.default]
DATABASE_URL = { description = "Database" }
API_KEY = { description = "API key" }
QUEUE_TOKEN = { description = "Queue token" }

[scopes.api]
secrets = ["DATABASE_URL", "API_KEY"]

[scopes.worker]
secrets = ["DATABASE_URL", "QUEUE_TOKEN"]

secretspec run --scope api -- ./api
secretspec run --scope worker -- ./worker

Composed secrets may still read hidden dependencies to build a visible value, but those inputs are not exposed to the child. The same scope selection is available to check, export, and the SDK builders. Scopes minimize secret delivery; they are not an authorization boundary when the child itself holds provider credentials.

Carrying the selected scope through resolver requests and results required a breaking change to secretspec-ffi. All SecretSpec SDKs have been updated for 0.17 to support scopes, so applications should upgrade their SDK package and bundled native resolver together.

Secrets caching

Many cloud providers take long enough to resolve a secret that their latency becomes part of every development command.

A single 1Password lookup can take roughly one second.

SecretSpec providers implement get_many so a backend can resolve several values together. Relatively few secret stores and CLIs expose a true bulk-read operation, however, so many providers still have to perform separate lookups.

Waiting on a remote service or its CLI every time makes check, run, and application startup feel slow, especially as a project grows.

A provider alias can now combine its authoritative fallback route with a local cache:

secretspec.toml

[providers]
vault = "vault://vault.example.com:8200/secret"
local = "keyring://secretspec/cache/{project}/{profile}/{key}"

fast_vault = {
  fallback = ["vault"],
  cache = { provider = "local", max_age = "8h" }
}

[profiles.default.defaults]
providers = ["fast_vault"]

Fresh entries avoid contacting the remote provider. A miss or expired entry falls through to Vault and refreshes the cache; writes update the authoritative provider first and then refresh or invalidate its cached copy. Route changes, reference changes, and writes that bypass the cached alias also invalidate the entry.

The cache is a real copy of the secret, so SecretSpec requires a distinct store that it can delete from and records ownership before changing an entry. secretspec cache clear [NAME] forces the next read back through the authoritative route.

Vault and OpenBao KV v2 caches are the only providers that handle max_age as server-side expiry properly.

None of SecretSpec’s current local providers has strong native support for expiry. They can remove an expired entry the next time SecretSpec sees it, but cannot ensure the local copy disappears at its deadline if SecretSpec never runs again.

Our planned FactorSeal provider in Future work is intended to close that gap with an explicit API for credential eviction among the other goals.

Cross-secret validation

Profiles can now express credential alternatives directly:

secretspec.toml

[profiles.default]
PASSWORD = { description = "Password", required = { at_least_one = "auth" } }
ACCESS_TOKEN = { description = "Token", required = { at_least_one = "auth" } }

GITHUB_TOKEN = { description = "GitHub token", required = { exactly_one = "github_auth" } }
GITHUB_APP_KEY = { description = "GitHub App private key", required = { exactly_one = "github_auth" } }

The auth group accepts a password, an access token, or both. The github_auth group requires exactly one credential and rejects configurations that provide both the token and the app key.

New providers

SOPS brings the encrypted-file workflow from our recent SOPS comparison behind SecretSpec’s provider-independent CLI and SDKs. SecretSpec delegates encryption and decryption to the installed SOPS CLI, so existing SOPS key services and .sops.yaml creation rules remain in control.

The provider reads and writes YAML, JSON, dotenv, and INI files, supports a single shared file or {project} / {profile} path templates, and can source sensitive SOPS inputs such as age keys or cloud credentials through provider credentials.

secretspec.toml

[providers]
sops = "sops://secrets/{project}/{profile}.enc.yaml"

[profiles.production.defaults]
providers = ["sops"]

age offers a smaller encrypted-file setup. It stores a dotenv-style secret set for one or more age recipients, including hybrid post-quantum recipients.

KeePass KDBX reads KDBX 3 and 4 databases and writes KDBX 4, with master passwords sourced from another provider rather than embedded in the URI.

OpenBao gets its own openbao:// identity and BAO_* configuration while sharing compatible KV, token, AppRole, and JWT mechanics with Vault. Both Vault and OpenBao can now exchange a JWT for a short-lived token, including an OIDC token minted automatically in GitHub Actions and Forgejo Actions with id-token: write.

Scaleway Secret Manager adds regional, project-aware cloud storage and read-only references to existing secrets and revisions.

systemd credentials is a read-only provider that resolves values from the current service’s $CREDENTIALS_DIRECTORY, including credentials used to bootstrap another provider.

GitHub and Forgejo Actions

Alongside 0.17, the new cachix/secretspec-action installs SecretSpec, resolves the selected profile, masks every value in the runner log, and adds the secrets to the environment of later job steps:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: cachix/secretspec-action@main
        with:
          profile: production
          scope: api
      - run: ./deploy.sh

A missing required secret fails the action, so the same step also checks that the deployment environment is complete. See the GitHub Actions guide for provider selection and tokenless Vault or OpenBao authentication through the runner’s OIDC identity.

Upgrading

SecretSpec 0.17 also brings:

Bitwarden Secrets Manager — now uses the separately installed official bws CLI instead of linking its SDK.
Non-interactive setup — secretspec config global init --provider ... --profile ... configures defaults without prompts.
Windows packages — for the Python, Ruby, and PHP SDKs.
Clearer status output — plus more controlled concurrency and retry behavior for Vault and OpenBao.

cargo install secretspec

See the full changelog for every change in this release.

Future work

The next work brings more control to local secret access:

GUI confirmation dialogs — approve or deny a secret request in a native prompt instead of requiring a terminal interaction.
A Passbolt provider — bring Passbolt’s open-source, collaboration-focused credential manager behind the same SecretSpec interface for cloud and self-hosted teams.
A Bitwarden Password Manager provider — resolve regular Bitwarden vault items, separately from the Bitwarden Secrets Manager provider already available in SecretSpec.
A JVM SDK — work is underway to bring the shared SecretSpec resolver to Java, Kotlin, and other JVM languages.
A FactorSeal provider — we have started work on a new Linux provider built around mandatory TPM-backed storage and secure defaults. FactorSeal also provides an explicit API for credential expiry, which is crucial for the caching work in this release: local copies can carry a defined eviction deadline instead of living without a retention policy. Still in development.

Questions or feedback? Join us on Discord.

But I Use SOPS

Thu, 23 Jul 2026 00:00:00 GMT

Whenever I show someone SecretSpec, I often hear the same response:

But I use SOPS.

SOPS is good. It encrypts files so they can live in Git without exposing their plaintext values.

But SecretSpec solves a different problem: how applications declare, find, and consume secrets.

How does your application use the secret?

Once you have encrypted secrets.yaml, how does your Python service consume it? What about your Go worker or Node.js app?

You still need to decrypt the file, inject its values, select the right file for each environment, validate required keys, and repeat that integration for every language.

And if you release the project as open source, that choice does not stay yours. With SOPS baked into the setup, everyone who runs or contributes to the project must adopt SOPS and its key management, whatever secrets tooling they already use.

SecretSpec starts at the other end. The project declares what the application needs without storing any values:

secretspec.toml

[project]
name = "payments"
revision = "1.0"

[profiles.default]
DATABASE_URL = { description = "Postgres connection string" }
STRIPE_API_KEY = { description = "Stripe secret key" }

The same secret can come from a developer’s system keyring or CI environment variables, while a more sensitive production environment resolves it from Vault. Applications use the same declaration through eight SDKs for Rust, Python, Go, Ruby, Node.js/TypeScript, Haskell, PHP, and C# without knowing the provider.

Encrypted files also make the key workflow a project-wide requirement. Adding a teammate means adding their key to .sops.yaml and re-encrypting every file; removing one means rekeying and rotating the affected secrets, since their key already saw the plaintext. SecretSpec leaves identity and access to the provider: onboarding to Vault or a cloud secrets manager is granting a role, and offboarding is revoking it.

SOPS may be enough today. As your team grows more sensitive to how secrets are handled, you may want Vault’s access policies and centralized audit trail. If applications know about SOPS, each one needs migrating. If they know only SecretSpec, you change the provider configuration; SDK calls and secret names stay the same.

The same resolver provides profiles, required-secret checks, per-secret provider routing and fallback, provider-native references, temporary files, and metadata-only audit logs. You build the integration once, not once per provider and language.

Different layers, different jobs

SOPS protects a file. SecretSpec gives applications a provider-independent interface. The selected provider remains responsible for storage, encryption, identity, access control, and availability.

I wrote a fuller SecretSpec comparison showing exactly where SecretSpec ends, where providers begin, and which responsibilities belong to each layer.

Where SecretSpec goes next

Because applications talk to an interface instead of a file, the interface can grow without touching them. Three open proposals point where it is heading:

Project security requirements would let a project declare the guarantees a provider must meet, such as encryption at rest or an audit trail, and reject providers that fall short.
Lease-aware refresh would let running applications follow key rotation and short-lived credentials instead of restarting for a new value.
The SOPS provider (0.17+) brings SOPS itself behind the same SDK interface, making your encrypted files one more place secrets can come from.

With that provider, perhaps “But I use SOPS” just needs two more words:

But I use SOPS with SecretSpec.

If encrypted files fit your workflow, keep using SOPS. Just recognize the boundary: encryption at rest is not an application secrets interface.

Secrets Don’t Belong in Config

Mon, 20 Jul 2026 00:00:00 GMT

Applications should not require passwords, API keys, or tokens in their configuration files.

Configuration describes behavior. It belongs in git, code review, bug reports, and developer machines.

A secret grants authority. It needs restricted access and independent rotation.

Putting both in one file couples different lifecycles and audiences. If rotating a password requires regenerating application configuration, the interface has coupled them too tightly.

NixOS contains 110 workarounds for this

We audited all 445 NixOS modules that handle a real secret in nixpkgs at commit 141f212, classifying each by where its secret value ends up.

Where the secret value ends up	Modules	Share
Merged into a config file at runtime	110	25%
Inlined into a config in `/nix/store`	42	9%
Delivered as an environment variable	161	36%
Left in a dedicated file opened by the app	58	13%
Loaded through systemd credentials	53	12%
Passed as a command-line argument	19	4%
Classification uncertain	2	—

The interesting number is 110. A quarter of the modules retrieve a secret safely, then copy it into configuration because that is the only interface the application accepts.

These modules use envsubst, replace-secret, jq, yq, sed, or custom code to assemble a restricted file at startup. The result can be secure, but every module now owns application-specific, security-sensitive glue just to combine two inputs that should have remained separate.

This is not unique to NixOS. The same workaround appears as an entrypoint script, Helm template, init container, or CI interpolation step on other platforms.

As a side note, 42 modules can inline secrets into the world-readable /nix/store. That direct security problem is tracked in nixpkgs issue #24288. The 110 runtime mergers make the broader point: even when deployment authors avoid the leak, the missing separation still creates work.

Give secrets their own interface

Applications should accept secret values through a dedicated runtime channel, such as:

a password_file or token_file setting;
a systemd credential;
a narrowly scoped environment variable;
or an external secret provider.

These mechanisms are not equally safe: environment variables can be inherited, arguments can appear in process listings, and files still need correct permissions. What separation does guarantee is that the deployer no longer has to manufacture a second, secret-bearing version of the configuration.

The principle is simple; implementing it across environments is not. Local development might use a system keyring, CI environment variables, and production 1Password or Vault. Without a shared abstraction, each environment needs its own naming, lookup, validation, and injection glue.

How I got it wrong in Cachix

Cachix historically stored its auth token and per-cache signing keys in ~/.config/cachix/cachix.dhall, alongside cache names and other configuration. It was convenient, but the file had to be treated as a secret even though much of it was ordinary configuration.

A typical file mixed them directly:

~/.config/cachix/cachix.dhall

{ authToken = "XXX-AUTH-TOKEN"
, binaryCaches =
    [ { name = "mycache"
      , secretKey = "XXX-SIGNING-KEY"
      }
    ]
}

The cache name is configuration; the auth token and signing key are secrets. You could not share the cache configuration without also sharing credentials.

devenv 2.2 separates the token through SecretSpec. The project declares CACHIX_AUTH_TOKEN, devenv resolves it from the configured provider, and the value is passed to Cachix without being added to devenv’s configuration.

Cachix PR #737 brings the same boundary into the client through the SecretSpec Haskell SDK. It resolves CACHIX_AUTH_TOKEN and CACHIX_SIGNING_KEY from SecretSpec and can store them in the user’s chosen provider instead of cachix.dhall. Existing environment variables and config files remain higher-priority fallbacks for compatibility. The PR is still open.

That is the problem SecretSpec is designed to solve: configuration declares the requirement, while each environment chooses where the value lives.

Declare once, resolve anywhere

SecretSpec applies that separation by making secretspec.toml a declaration of what an application needs, without storing the values:

secretspec.toml

[project]
name = "myapp"

[profiles.production]
DATABASE_URL = { description = "Postgres connection string" }
STRIPE_API_KEY = { description = "Stripe secret key" }

Providers decide where the values live. A developer can use the system keyring, CI can use environment variables, and production can use 1Password, Vault/OpenBao, or a cloud secret manager without changing the declaration.

An existing application can receive the resolved values at startup:

secretspec run -- ./myapp

Applications can also resolve them directly through the SecretSpec SDKs for Rust, Python, Go, Ruby, Node.js/TypeScript, Haskell, PHP, and C#, all sharing the same resolver so behavior stays consistent across languages.

Providers own where secret values come from. SDKs give applications an idiomatic way to consume them. Configuration remains a shareable declaration of what is required.

Making the boundary practical

If you maintain an application, stop adding passwords and tokens to ordinary configuration schemas. Accept a file reference, credential, environment variable, or provider instead.

For NixOS, SecretSpec issue #65 tracks how an official integration could declare and resolve secrets without per-module substitution glue.

Consistent secret handling across developer machines, CI, and production used to require infrastructure that only dedicated platform teams could build. A project of any size should be able to separate secrets from configuration without building its own secrets platform first.

SecretSpec 0.16: Composed secrets, Infisical, and C# SDK

Sat, 18 Jul 2026 00:00:00 GMT

SecretSpec 0.16 ships:

Composed secrets — derive a read-only value, such as a connection string, from other secrets declared in the manifest.
Infisical — read and write secrets in Infisical Cloud or a self-hosted instance, with Universal Auth, access-token, and provider-credential authentication.
C# SDK — resolve the same manifests from .NET through the shared native resolver, distributed as the Cachix.SecretSpec NuGet package.

Composed secrets

Applications often need a connection string while secret stores work better with its independently rotated parts. SecretSpec can now keep those parts separate and assemble the application-facing value when it resolves the manifest:

secretspec.toml

[profiles.default]
DB_USER = { description = "Database user" }
DB_PASSWORD = { description = "Database password" }
DB_HOST = { description = "Database host" }

DATABASE_URL = {
  description = "PostgreSQL connection string",
  composed = "postgres://${DB_USER}:${DB_PASSWORD}@${DB_HOST}/app"
}

DB_USER, DB_PASSWORD, and DB_HOST still come from their configured providers. DATABASE_URL is assembled in memory and behaves like any other resolved secret in the CLI and SDKs. Compositions are read-only, may build on other compositions, and are checked for missing references and cycles before resolution.

See Composed Secrets for optional values, escaping, profile inheritance, and validation rules.

Infisical

The new infisical:// provider works with Infisical Cloud, its EU service, and self-hosted instances. Point SecretSpec at an Infisical project and authenticate with Universal Auth:

export INFISICAL_CLIENT_ID=...
export INFISICAL_CLIENT_SECRET=...

secretspec run \
  --provider "infisical://app.infisical.com/7e2f1a4c-...?env=prod" \
  -- npm start

Access tokens are also supported. Credentials can come from environment variables or SecretSpec’s provider credentials, allowing, for example, an Infisical machine identity to be kept in the system keyring:

secretspec.toml

[providers.infisical]
uri = "infisical://app.infisical.com/7e2f1a4c-..."

[providers.infisical.credentials]
client_id = "keyring"
client_secret = "keyring"

By default, the active SecretSpec profile also names the Infisical environment. A production profile therefore reads from the production environment, while ?env= can select a different one. The provider supports normal SecretSpec reads and writes, as well as references to existing Infisical secrets and versions.

See the Infisical provider guide for self-hosting, authentication, paths, references, and permissions.

C# SDK

The Cachix.SecretSpec NuGet package brings the shared SecretSpec resolver to .NET 8:

dotnet add package Cachix.SecretSpec

using Cachix.SecretSpec;

using var resolved = SecretSpec.Builder()
    .WithProvider("keyring://")
    .WithProfile("production")
    .WithReason("boot web app")
    .Load();

Console.WriteLine(resolved.Secrets["DATABASE_URL"].Get());
resolved.SetAsEnv();

It uses the same resolver as the CLI and other language SDKs, so profiles, providers, fallback chains, references, generators, audit reasons, and composed secrets work consistently in .NET. Native resolver builds are included in the NuGet package, with no separate SecretSpec CLI installation required.

See the C# SDK guide for supported platforms, ASP.NET Core integration, preflight reports, error handling, and typed access.

Upgrading

cargo install secretspec

All three additions are opt-in: existing manifests and provider configurations continue to work unchanged. Add composed when a value should be derived, select an infisical:// provider to use Infisical, or install Cachix.SecretSpec in a .NET application.

See the full changelog for every change in this release.

Questions or feedback? Join us on Discord.

SecretSpec 0.15: Provider credentials, Azure Key Vault / Gopass, and PHP SDK

Thu, 16 Jul 2026 00:00:00 GMT

SecretSpec 0.15 ships:

Provider credentials — authenticate one secret provider with credentials stored in another, without exporting them to the application environment.
Azure Key Vault — store and resolve secrets with service-principal, Azure CLI, managed-identity, or AKS workload-identity authentication.
Gopass — use a GPG-encrypted, git-synchronized password store, including multi-user and multi-store setups.
PHP SDK — use the shared SecretSpec resolver from PHP-FPM, Laravel, Symfony, and CLI applications through a native extension or ext-ffi.
AWS creation guardrails — set a customer-managed KMS key and required tags when SecretSpec creates an AWS Secrets Manager secret.
secretspec export — resolve secrets without launching a command, with shell, dotenv, JSON, and GitHub Actions output.
Provider and resolution fixes — ordered lazy fallback chains, early ref validation, correctly merged profile overrides, stable output, and broader Node.js Linux compatibility.

Credentials for the secret store

Suppose Bitwarden Secrets Manager holds an application’s secrets, but its machine access token is kept in the user’s OS keyring. Declare the relationship on the provider alias:

secretspec.toml

[providers]
keyring = "keyring://"

[providers.bws]
uri = "bws://a9230ec4-5507-4870-b8b5-b3f500587e4c"

[providers.bws.credentials]
access_token = "keyring"

Before SecretSpec connects to Bitwarden, it reads access_token from the keyring at the normal {project}/{profile}/access_token address. The active profile is part of that address, so production and development can authenticate as different machines without changing the alias.

When a credential already has a provider-native address, use a ref. Here a Vault AppRole is kept as two fields of one 1Password item:

secretspec.toml

[providers.vault_prod]
uri = "vault://secret/myapp?auth=approle"

[providers.vault_prod.credentials]
role_id.provider = "onepassword"
role_id.ref.vault = "Infra"
role_id.ref.item = "vault-approle"
role_id.ref.field = "role_id"

secret_id.provider = "onepassword"
secret_id.ref.vault = "Infra"
secret_id.ref.item = "vault-approle"
secret_id.ref.field = "secret_id"

The credential source uses the same ref coordinates as application secrets. The difference is where the value goes: SecretSpec hands it directly to the destination provider in memory. It is not added to the environment of a process started by secretspec run.

Provider credential names are semantic and checked before a source is opened. Bitwarden accepts access_token; Vault accepts token, role_id, and secret_id; 1Password accepts service_account_token; Azure Key Vault accepts tenant_id, client_id, and client_secret. A configured credential is authoritative, while a provider’s usual environment fallback remains available when no credential source is declared.

Credential chains deliberately stop after one hop. The store containing a provider credential cannot itself depend on another provider credential. This keeps the bootstrap path finite and makes dependency mistakes fail before any store is contacted.

Log in once, without an environment variable

The new config provider login command prompts for every credential an alias declares and writes it to the configured source:

$ secretspec config provider login bws
Enter access_token for provider 'bws' (source: keyring): ****
✓ stored access_token in keyring at my-app/default/access_token

A user-level alias and its credential source can also be declared entirely with config provider add:

secretspec config provider add bws "bws://project-uuid" \
  --credential access_token=keyring
secretspec config provider login bws

Credentials are fetched once per invocation and profile, then reused for every secret routed through that alias. Each credential read, and each value stored by login, gets an audit event marked with the semantic credential name and source store. As with every SecretSpec audit event, the credential value is never recorded.

See Provider Credentials for the full configuration and resolution rules.

Azure Key Vault

Azure Key Vault joins the provider list with the akv:// scheme:

# Use service-principal credentials, or the current Azure CLI session
secretspec run --provider akv://myvault -- npm start

# Use the platform's managed identity
secretspec check --provider akv://myvault?auth=managed_identity

# Use AKS workload identity federation
secretspec run --provider akv://myvault?auth=workload_identity -- ./deploy

The default authentication mode first looks for the tenant_id, client_id, and client_secret provider credentials introduced above, then their AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET environment fallbacks. If none are present, it uses the signed-in Azure CLI or Azure Developer CLI session. A partial service principal is an error, rather than a reason to silently switch identities.

That makes a service principal straightforward to keep in the system keyring:

secretspec.toml

[providers.azure]
uri = "akv://myvault"

[providers.azure.credentials]
tenant_id = "keyring"
client_id = "keyring"
client_secret = "keyring"

secretspec config provider login azure
secretspec run --provider azure -- ./deploy

Sovereign clouds can use either a complete vault hostname or an explicit DNS suffix such as akv://myvault?suffix=vault.azure.cn.

Azure restricts secret names to letters, digits, and hyphens and compares them case-insensitively. SecretSpec encodes the project, profile, and key as lowercase, unpadded Base32 components. The encoding keeps names that differ by case or punctuation distinct instead of letting Azure collapse them onto the same secret. Existing Azure secrets can be addressed with a read-only ref.

See the Azure Key Vault provider guide for authentication, naming, references, and required permissions.

Gopass joins the local providers

The new gopass:// provider reads and writes through the gopass CLI. Gopass builds on the Unix pass provider with multi-user and multi-store support while keeping entries GPG-encrypted and synchronized through git.

Once Gopass is installed and its password store is initialized, select it like any other provider:

secretspec set DATABASE_URL --provider gopass
secretspec run --provider gopass -- npm start

By default, entries live under secretspec/{project}/{profile}/{key}. A custom URI can change that layout, including omitting {project} to share secrets between repositories:

~/.config/secretspec/config.toml

[defaults.providers]
shared = "gopass://secretspec/shared/{profile}/{key}"

An existing Gopass entry can also be addressed directly with a ref, including the mount-point prefix used by a multi-store setup. See the Gopass provider guide for installation, shared-store configuration, references, and current limitations.

PHP joins the SDKs

The new cachix/secretspec Composer package brings the shared resolver to PHP:

composer require cachix/secretspec

<?php

use Secretspec\SecretSpec;

$resolved = SecretSpec::builder()
    ->withProfile('production')
    ->withReason('boot web app')
    ->load();

echo $resolved->secrets['DATABASE_URL']->get();
$resolved->setAsEnv();

It offers two native backends behind the same PHP API. The recommended native extension embeds the resolver and works under PHP-FPM without ffi.enable, like ext-redis. An ext-ffi fallback loads the shared resolver at runtime for CLI tools and local development. Both use the same Rust core as the CLI and the other language SDKs, so profiles, providers, fallback chains, generators, as_path, audit reasons, and typed missing-secret errors behave the same way.

setAsEnv() updates getenv(), $_ENV, and $_SERVER, which lets Laravel’s env() helper and Symfony’s %env(...)% processors consume resolved secrets during application boot. See the PHP SDK guide for installation and framework examples.

AWS creation guardrails

AWS accounts often require a customer-managed KMS key or specific tags in the same CreateSecret request. The AWS Secrets Manager provider now accepts both on its URI:

secretspec.toml

[providers]
prod = "awssm://prod@us-east-1?kms_key_id=alias/my-key&tag.team=platform&tag.env=prod"

kms_key_id and repeatable tag.NAME=VALUE parameters are applied only when SecretSpec creates a secret. Updating an existing secret does not alter the key or tags it was created with. This supports tag-on-create SCP and IAM guardrails without turning routine secret updates into infrastructure changes.

Export secrets for shells, tools, and CI

The new export command resolves every secret for the active profile without starting another process. Its default output can be evaluated by a POSIX shell:

eval "$(secretspec export --profile production)"

Use --format dotenv to write dotenv syntax or --format json to pass the resolved values to another tool:

$ secretspec export --profile production --format json
{
  "DATABASE_URL": "postgresql://prod.example.com/mydb"
}

GitHub and Forgejo Actions can use --format gha. SecretSpec masks every value in the runner log and appends it to $GITHUB_ENV, making the secrets available to later steps and third-party actions:

- name: Export secrets
  run: secretspec export --profile production --format gha
- name: Deploy
  run: ./deploy

Like non-interactive check, export never prompts and exits non-zero when a required secret is missing, so it can gate a CI job. Export attempts are also recorded in the audit log. See the export CLI reference for every format and option.

Provider and resolution fixes

0.15 also tightens the behavior around profiles and fallback chains:

Provider chains are now walked strictly in order and resolved lazily. An undefined alias or unreachable fallback is skipped with a warning only when a read reaches it, so a later working provider can still answer.
Chain entries accept aliases, bare provider names such as keyring, shorthand such as dotenv:.env, and complete provider URIs.
A single destination provider rejects unsupported ref coordinates before contacting the store. Multi-provider chains still validate each destination as they reach it, because an earlier store may support coordinates a later one does not.
Profile overrides inherit the base secret’s description and generation type. Validation now uses the effective merged secret while still catching real conflicts, such as combining generate with a profile default.
run passes non-UTF-8 environment variables through to the child untouched, and command output that previously depended on map order is now stable.
Prebuilt Node.js addons now target glibc 2.28 and statically include libdbus, restoring support for Amazon Linux 2023, RHEL 8/9, and similar distributions.

Upgrading

cargo install secretspec

Existing providers retain their conventional environment authentication when an alias does not declare credentials. Provider credentials are opt-in, and credential dependency chains are limited to one hop.

See the full changelog for every change and fix in this release.

Questions or feedback? Join us on Discord.

SecretSpec 0.14: Secret references

Thu, 09 Jul 2026 00:00:00 GMT

SecretSpec keeps a secretspec.toml that declares what secrets an application needs, and resolves the values from a provider: your system keyring, 1Password, Vault, a .env file, and so on. Until now it stored every secret under a naming convention it controlled, secretspec/{project}/{profile}/{key}, and that convention was the only place it looked.

That works when SecretSpec created the secret. It does not when the secret already exists under a name something else chose: a db item in a 1Password vault, a myapp/config path at a Vault mount, an environment variable your platform already sets. To manage such a secret you had to copy its value into SecretSpec’s convention, leaving two copies to rotate, or leave it out of SecretSpec entirely.

SecretSpec 0.14 introduces ref. A secret can name one that already exists, by the store’s own coordinates, and SecretSpec reads and writes that secret in place:

[profiles.production]
DATABASE_URL = { description = "Postgres DSN", ref = { item = "db", field = "password" }, providers = ["prod_op"] }

DATABASE_URL now resolves from the password field of the 1Password item db. SecretSpec does not prepend a project or profile, and does not create a name of its own.

Why not just paste the address

1Password will give you an address for that field: op://Production/db/password. The obvious design is to accept that string in the config and be done. We built that first and removed it.

A string like op://Production/db/password names the store and the secret at the same time, which ties the secret to 1Password. The same reference cannot then resolve from Vault in CI and 1Password on a laptop, cannot be redirected at a .env fixture for a test run without editing the manifest, and does not compose with a provider fallback chain, because the chain and the address disagree about where the secret is.

SecretSpec already decides which store to use, through providers, profiles, fallback chains, and the --provider override. A ref names only the secret and leaves the store to that existing machinery.

Coordinates

A ref is a table, not a URL. Each key names a level of structure that some stores have:

vault                which container holds the item        (1Password only)
└── item             the store's own name for the secret   (always required)
    └── section      a named group of fields               (1Password only)
        └── field    one component inside the item          (structured stores)
            └── version   which revision to read            (GCSM only)

Only item is required, because every store names its secrets somehow. item is the complete name: it replaces the whole convention path, with no project or profile and no folder prefix prepended. ref = { item = "GITHUB_PAT" } on the env provider reads the environment variable GITHUB_PAT and nothing else.

The other keys refine item for stores that have that structure. A .env key holds a single value, so field on a dotenv ref is not meaningful. A Vault KV entry is a map, so field is required. When a store has no equivalent for a coordinate it reports an error naming that coordinate, rather than reading a different secret:

GITHUB_TOKEN = { description = "GitHub token", ref = { item = "GITHUB_PAT", field = "x" }, providers = ["env"] }

Error: Provider operation failed: the env provider does not support the `field` coordinate. Drop `field` from the ref for `GITHUB_PAT`.

All eleven providers resolve refs, and each rejects the coordinates it cannot represent. A store whose secrets have no internal parts gets that rejection from shared code, without any per-provider work.

References name, providers route

A ref supplies the name only. Which provider resolves it follows the normal provider resolution order: a --provider override, then the secret’s providers chain, then profile and global defaults. That is the same order every other secret uses.

Because the store is not part of the reference, the same ref works across providers. Each provider in a fallback chain is asked for the same coordinates, and one that cannot interpret them logs a warning and the chain continues:

[profiles.production]
DATABASE_URL = { description = "Postgres DSN", ref = { item = "db", field = "password" }, providers = ["onepassword://Production", "keyring"] }

Chain entries can also be inline scheme:// URIs, as above, with no [providers] alias declared first.

The --provider override redirects a referenced secret the same way it redirects a conventional one, so pointing a whole suite at a .env fixture needs no change to the manifest:

$ secretspec run --provider dotenv:.env.fixtures -- cargo test

Writing through a ref

Reads and writes use the same coordinates. secretspec set and interactive check write to the referenced secret in place wherever the store supports writes:

$ secretspec set DATABASE_URL
# writes the `password` field of the 1Password item `db`, in place

1Password edits the field with op item edit and does not create items. Keyring, pass, dotenv, Bitwarden, Proton Pass, and LastPass write their refs as well. Vault, AWS Secrets Manager, and Google Secret Manager are read-only for refs and report that directly, rather than claiming the provider cannot write at all.

A ref also composes with generate. If the referenced secret does not exist yet, SecretSpec generates the value and writes it to the coordinates, so the first check populates the item everything else already reads.

Faster resolution

check, run, and the SDKs now group secrets by store and fetch the groups concurrently instead of one store after another. Within a group, referenced secrets use the store’s bulk API where it has one (AWS BatchGetSecretValue, and the single Bitwarden, Proton Pass, and 1Password listings) and otherwise resolve concurrently, fetching each unique coordinate once. CLI authentication for 1Password, LastPass, and Proton Pass is probed once per account or session instead of once per provider instance.

Upgrading

cargo install secretspec

Three changes to be aware of:

A onepassword:// URI carrying an item path used to drop the path and target a vault literally named vault. Item paths, including pasted op://vault/item/field strings, now fail with an error that gives the ref table to write instead. Provider URIs are store addresses only.
ref is always a table. String and URI forms are rejected, with the same translation in the error.
Manifest validation now runs on every load. Rules that secretspec.toml documents (a required secret cannot have a default, generate needs a type, ref coordinates must be non-empty) are enforced on load rather than ignored. A manifest that violated one of them will now fail with a clear error.

See Secret References for the full model and the configuration reference for how each provider maps the coordinates. Questions or feedback? Join us on Discord.

SecretSpec 0.13: SDKs for Python, Node.js, Go, Ruby, and Haskell

Fri, 03 Jul 2026 00:00:00 GMT

SecretSpec separates what secrets an application needs, declared in secretspec.toml, from where the values live, a provider like your system keyring, 1Password, or Vault. Until now, reading those resolved secrets at runtime meant the CLI or the Rust SDK. If your service was written in Python or Go, you shelled out to secretspec run or reimplemented resolution yourself.

SecretSpec 0.13 closes that gap. It ships native SDKs for five languages: Python, Node.js / TypeScript, Go, Ruby, and Haskell. Each resolves the exact secrets your manifest declares, through the same providers, profiles, fallback chains, and generators as the CLI, with no per-language configuration.

Native bindings over one resolver

Every SDK is a thin client over the same Rust core that powers the CLI. No provider logic, profile resolution, chain fallback, as_path materialization, or secret generation lives in the binding. A provider added to SecretSpec works in every language the day it lands, and every SDK behaves identically.

The binding strategy is chosen per ecosystem:

Python: a pyo3 extension, statically linked, shipped as a self-contained cp39-abi3 wheel.
Node.js: a napi-rs addon with prebuilt per-platform packages.
Ruby: a native C extension (mkmf) with the resolver statically linked into a platform gem.
Go: the secretspec-ffi C ABI loaded at runtime via purego (no cgo).
Haskell: the same C ABI, linked at build time through the Haskell FFI.

The same three steps, in your language

Each SDK mirrors the vocabulary of the Rust derive crate: a builder that takes a provider, a profile, and an access reason, then load() to resolve, then a map of secrets you can read or export into the environment.

# Python
from secretspec import SecretSpec

resolved = (
    SecretSpec.builder()
    .with_provider("keyring://")
    .with_profile("production")
    .with_reason("boot web app")
    .load()
)
print(resolved.secrets["DATABASE_URL"].get)  # value, or file path for as_path
resolved.set_as_env()                         # export into os.environ

// Node.js / TypeScript
const { SecretSpec } = require('secretspec');

const resolved = SecretSpec.builder()
  .withProvider('keyring://')
  .withProfile('production')
  .withReason('boot web app')
  .load();
console.log(resolved.secrets.DATABASE_URL.get()); // value, or as_path file path
resolved.setAsEnv();                              // export into process.env

// Go
resolved, err := secretspec.New().
    WithProvider("keyring://").
    WithProfile("production").
    WithReason("boot web app").
    Load()
fmt.Println(resolved.Secrets["DATABASE_URL"].Get()) // value, or as_path file path
resolved.SetAsEnv()                                 // export into the environment

# Ruby
resolved = Secretspec::SecretSpec.builder
                                 .with_provider("keyring://")
                                 .with_profile("production")
                                 .with_reason("boot web app")
                                 .load
puts resolved.secrets["DATABASE_URL"].get # value, or as_path file path
resolved.set_as_env!                      # export into ENV

-- Haskell
resolved <-
  S.load
    ( S.builder
        & S.withProvider "keyring://"
        & S.withProfile "production"
        & S.withReason "boot web app"
    )
S.setAsEnv resolved -- export into the environment

Across all of them, load() resolves every declared secret, a missing required secret raises a typed MissingRequiredError, and as_path secrets come back as a readable file path with a cleanup that removes the backing temp file. The access reason feeds the same audit log and require_reason policy from 0.12, so a Go service is as accountable as the CLI.

Write your own binding

Under all five SDKs sits a new crate, secretspec-ffi: a small, versioned C ABI for resolving secrets. If we do not ship your language yet, you can bind to it directly. It also exposes the public Rust building blocks the SDKs share, Secrets::resolve() and Secrets::report(), so a Rust program reaches the same value-carrying and value-free entry points.

Typed secrets, one schema for every language

secretspec.toml already knows the shape of your secrets, so 0.13 can hand that shape to your type system. secretspec schema emits a JSON Schema for your manifest, the union of all profiles or one profile with --profile. Pipe it through quicktype to generate idiomatic typed classes in any language, then populate them from each SDK’s fields() map:

secretspec schema | quicktype -s schema --top-level SecretSpec --lang python -o secrets_gen.py

typed = Secrets.from_dict(resolved.fields())
print(typed.database_url)  # typed str

One schema drives every language’s type system, with no hand-written emitter per language.

Install

pip install secretspec                              # Python
npm install secretspec                              # Node.js / TypeScript
gem install secretspec                              # Ruby
go get github.com/cachix/secretspec/secretspec-go   # Go

For Haskell, add secretspec from Hackage to your build-depends. The CLI and Rust SDK upgrade as usual:

cargo install secretspec

See the SDK overview for the per-language guides. Questions or feedback? Join us on Discord.

SecretSpec 0.12: Audit logs and coding agents

Mon, 08 Jun 2026 00:00:00 GMT

A coding agent reaches for the same secrets you do, but on its own initiative and many times a session: a read looks identical whether it came from you running a deploy or an agent exploring the codebase.

SecretSpec 0.12 makes that access accountable. It ships three things:

Audit log — every secret read and write is appended to a local, per-user JSONL log. On by default. Values are never recorded.
Reason-on-access — secret access can require a human-readable reason, enforced for coding agents by default.
secretspec audit command — filter and summarize the log, or pipe raw JSON Lines to jq.

The audit log

Every secret read and write, from the CLI and the Rust SDK, is appended to a local log as JSON Lines, one event per line. Secret values are never written, only metadata: the secret name, the profile, the provider that served it (with any embedded credentials redacted), the outcome, the reason, and who was asking, including the detected coding agent.

{
  "v": 1,
  "ts": "2026-06-04T17:04:00.893Z",
  "action": "get",
  "project": "my-app",
  "profile": "production",
  "key": "DATABASE_URL",
  "provider": "keyring://",
  "outcome": "found",
  "reason": "deploy web frontend",
  "actor": { "user": "alice", "agent": "claude-code", "is_agent": true },
  "version": "0.12.0"
}

The log lives in your per-user state directory (~/.local/state/secretspec/audit.log) and is created readable only by you. Read it with any tool, or use the new secretspec audit command for filtering and a readable summary:

# Last 20 entries, formatted
secretspec audit -n 20

# Only `run` events for one project
secretspec audit --project my-app --action run

# Raw JSON Lines, piped to jq
secretspec audit --json | jq 'select(.outcome == "missing")'

It is configured in your user-global config (~/.config/secretspec/config.toml), not the project’s secretspec.toml, so a repository you clone can’t quietly turn off or redirect your audit log. The log is a single file capped at 1 MiB, a size-bounded recent record rather than permanent compliance history; forward it to a central system if you need that. To turn it off entirely:

~/.config/secretspec/config.toml

[audit]
enabled = false

See Audit Logging for the full record schema and options.

Supplying a reason

When a coding agent like Claude Code reaches for a secret without a reason, the access is refused and the agent is told exactly what to do next:

$ secretspec run -- npm test
Error: Accessing secrets requires a reason. Provide one with --reason
"<why you are accessing these secrets>", the SECRETSPEC_REASON environment
variable, or Secrets::with_reason() in the SDK. (Policy: require_reason in
[project] of secretspec.toml — defaults to "agents"; set it to false to
disable.)

Claude Code reads that message, states why it needs the secret, and retries:

secretspec run --reason "run the test suite before opening a PR" -- npm test

Both the refusal and the successful retry land in the audit log, so the reason is tied to the access. There are three ways to supply a reason:

Source	Scope	Precedence
`--reason` flag	CLI	highest
`Secrets::with_reason()`	SDK	overrides env
`SECRETSPEC_REASON`	CLI + SDK + derive	lowest

# CLI: the most explicit option, overrides the others
secretspec run --reason "deploying release 0.12" -- ./deploy.sh

// SDK: the programmatic equivalent of --reason
let secrets = Secrets::load(/* ... */)?.with_reason("nightly backup job");

# Env: lowest precedence, but honored everywhere
export SECRETSPEC_REASON="nightly backup job"

SECRETSPEC_REASON is resolved by Secrets::load / load_from, which means secretspec-derive-generated code and other library callers satisfy the policy and supply an audit reason without any code changes.

Whichever path you use, blank or whitespace-only reasons are ignored, so they can’t quietly satisfy the policy. Under the hood this is backed by a new Provider::set_reason trait method (a no-op by default), so existing providers keep working unchanged.

Configuring when a reason is required

The new require_reason policy in the [project] table controls when a reason is mandatory:

[project]
name = "my-app"
require_reason = "agents"  # require it from agents (default), or true / false

"agents" (the default): require a reason only when a coding agent is detected.
true: require it from every caller.
false: never require it.

Because the policy lives in secretspec.toml and is enforced by SecretSpec, it applies to everyone and every CI runner, and is inherited through extends. Coding agents are spotted by the detect-coding-agent crate (Claude Code, Cursor, Codex, Gemini CLI, Copilot, and more); set SECRETSPEC_AGENT for a harness it doesn’t recognize.

Upgrading

cargo install secretspec

Remember the new default: agents must pass a reason: set require_reason = false to opt out.

Questions or feedback? Join us on Discord.

SecretSpec | Blog

Where .env Went Wrong

Environment variables only deliver values

A string is not a schema

Then the file starts to multiply

There is no .env spec

Which value wins?

Who loaded .env first?

An ignored file is still a file

Let .env become small again

How SecretSpec applies this

SecretSpec 0.17: Scopes, secrets caching, SOPS, age, and systemd credentials

Scopes

Secrets caching

Cross-secret validation

New providers

GitHub and Forgejo Actions

Upgrading

Future work

But I Use SOPS

How does your application use the secret?

Different layers, different jobs

Where SecretSpec goes next

Secrets Don’t Belong in Config

NixOS contains 110 workarounds for this

Give secrets their own interface

How I got it wrong in Cachix

Declare once, resolve anywhere

Making the boundary practical

SecretSpec 0.16: Composed secrets, Infisical, and C# SDK

Composed secrets

Infisical

C# SDK

Upgrading

SecretSpec 0.15: Provider credentials, Azure Key Vault / Gopass, and PHP SDK

Credentials for the secret store

Log in once, without an environment variable

Azure Key Vault

Gopass joins the local providers

PHP joins the SDKs

AWS creation guardrails

Export secrets for shells, tools, and CI

Provider and resolution fixes

Upgrading

SecretSpec 0.14: Secret references

Why not just paste the address

Coordinates

References name, providers route

Writing through a ref

Faster resolution

Upgrading

SecretSpec 0.13: SDKs for Python, Node.js, Go, Ruby, and Haskell

Native bindings over one resolver

The same three steps, in your language

Write your own binding

Typed secrets, one schema for every language

Install

SecretSpec 0.12: Audit logs and coding agents

The audit log

Supplying a reason

Configuring when a reason is required

Upgrading

There is no `.env` spec

Who loaded `.env` first?

Let `.env` become small again