Secretspec 0.18: Secret Lifecycle, Bitwarden, Keeper, AWS PS, and Swift

SecretSpec 0.18: Secret lifecycle, Bitwarden, Keeper, AWS Parameter Store, and Swift | SecretSpec Skip to content

SecretSpec 0.18: Secret lifecycle, Bitwarden, Keeper, AWS Parameter Store, and Swift

Aug 3, 2026 Domen Kožar

SecretSpec 0.18 ships:

Secret lifecycle commands : add declarations, delete stored values, and move secrets between providers without leaving the source copy behind.

Provider-backed discovery : initialize a manifest from an age file, an AWS Parameter Store hierarchy, or a Bitwarden collection without writing any values to it.

Four new providers : use Bitwarden Password Manager, Keeper Secrets Manager, AWS Systems Manager Parameter Store, and Dashlane through the same CLI and SDK interface.

Swift SDK : resolve manifests natively on macOS through a checksummed XCFramework that includes the shared Rust resolver.

Vault and OpenBao authentication : use custom AppRole and JWT mounts, AppRoles without SecretID binding, and server-configured default JWT roles.

We have a new logo! Section titled “We have a new logo!”

Secret lifecycle commands Section titled “Secret lifecycle commands”

SecretSpec has always kept the declaration in secretspec.toml separate from the stored value. 0.18 brings both sides of that lifecycle into the CLI.

secretspec add adds a declaration to the selected profile while preserving the manifest’s comments, formatting, and unrelated tables:

Terminal window$ secretspec add STRIPE_API_KEY --description "Stripe API access token"

✓ Added secret 'STRIPE_API_KEY' to profile 'default' in secretspec.toml

Set its value with: secretspec set STRIPE_API_KEY --profile default

$ secretspec set STRIPE_API_KEY

Enter value for STRIPE_API_KEY: ********

✓ Secret 'STRIPE_API_KEY' saved to keyring (profile: default)

add never asks for or stores the value. The declaration can be reviewed and committed before each developer or deployment supplies its own value.

secretspec delete does the inverse on the storage side: it removes a value without changing the declaration. The next check therefore reports the secret as missing instead of quietly removing the application’s requirement:

Terminal window$ secretspec delete STRIPE_API_KEY

Deleted 'STRIPE_API_KEY'

Deleted 1 secret value; 0 already absent

Deletion is idempotent, invalidates an associated cache entry, and follows the same primary-write-provider routing as set. delete --all requires an interactive confirmation, or an explicit --yes in non-interactive use.

Provider migrations can now remove each source value after proving the move succeeded:

Terminal windowsecretspec import dotenv:~/.config/payments/.env --delete-source

import --delete-source reads the destination back and compares it with the source before deleting anything. An identical value already at the destination is safe to remove from the source; a conflicting value leaves the source intact. SecretSpec also rejects a source without deletion support before writing the destination and recognizes equivalent provider spellings as the same store, so a migration cannot delete the value it just wrote through another alias.

Together these commands keep the distinction explicit: add changes what the application declares, set and delete change one environment’s stored value, and import --delete-source moves that value between stores.

Provider-backed discovery Section titled “Provider-backed discovery”

The first SecretSpec command in an existing project is often secretspec init --from .env. In 0.18, init --from accepts every provider that can discover declarations, including age, AWS Parameter Store, and Bitwarden Password Manager.

Hierarchical stores also receive an explicit project and profile so SecretSpec looks only inside the namespace the new manifest will use:

Terminal window$ secretspec init \

--from 'awsps://production@us-east-1?template=/{profile}/{project}/{key}' \

--project payments \

--profile production

✓ Created secretspec.toml with 12 secrets

For a password-manager vault, scope discovery to the collection and item type that belong to the application:

Terminal window$ secretspec init --from 'bw://Acme%20Inc@dev-secrets?type=login'

✓ Created secretspec.toml with 8 secrets

Discovery writes names and generated descriptions, never secret values. After reviewing the manifest, keep the discovered provider as the profile’s source or use secretspec import to copy the now-declared values somewhere else.

Four new providers Section titled “Four new providers”

0.18 brings SecretSpec to 24 providers, with four additions spanning personal password managers, machine-oriented vaults, and cloud parameter storage.

Bitwarden Password Manager is separate from the existing Bitwarden Secrets Manager provider. The new bw:// provider uses the official bw CLI to read and write regular vault items: logins, secure notes, cards, identities, and SSH keys. It can address organizations and collections by name or ID, restrict a provider to one item type or field, discover...

Secretspec 0.18: Secret Lifecycle, Bitwarden, Keeper, AWS PS, and Swift

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills