fnox

Fort Knox for your secrets.

fnox loads secrets into your commands from encrypted files, password managers, and cloud services. Keep the configuration in fnox.toml, choose where each secret lives, and use the same command in development and CI:

fnox exec -- npm start

Documentation · Quick start · Providers · CLI reference

Get started

Install with mise:

mise use -g fnox

Or with Rust: cargo install fnox --locked. See installation for other methods and updates.

In your project, run the setup wizard and configure a provider before storing a secret:

fnox init

# Use the default provider selected in the wizard; the value is prompted
fnox set DATABASE_URL

# Check access, then run your application
fnox check --all
fnox exec -- npm start

The provider determines where the value is stored. Without a provider, fnox set writes a plaintext default. Follow the age quick start for a complete encrypted setup, or connect an existing vault.

One config, your choice of storage

With a remote provider, value is a reference. This example reads an existing 1Password item:

# fnox.toml
[providers.op]
type = "1password"
vault = "Engineering"

[secrets]
DATABASE_URL = { provider = "op", value = "Database/url" }
LOG_LEVEL = { default = "info" } # Non-sensitive configuration

[profiles.production.providers.aws]
type = "aws-sm"
region = "us-east-1"
prefix = "myapp/"

[profiles.production.secrets]
DATABASE_URL = { provider = "aws", value = "database-url", if_missing = "error" }

fnox exec -- npm start
fnox exec --profile production -- ./deploy.sh

With an encryption provider, fnox set writes ciphertext into fnox.toml. Commit the ciphertext and public recipients; keep private keys outside the repository. Teammates need a matching private key or access to the configured vault.

Fit secrets into your workflow

• Load on directory change. Shell hooks load and unload secrets as you move between projects. Bash, Zsh, Fish, Nushell, and PowerShell are supported.
• Cache a vault locally. fnox sync encrypts a personal cache for offline use with a local provider such as age. Refresh it when vault values change.
• Cache in memory. The optional daemon reuses resolved values during your session.
• Separate environments. Compose profiles, share settings across a monorepo, and keep personal overrides in fnox.local.toml.
• Use temporary credentials. Create short-lived credentials with AWS STS, GitHub Apps, Vault, and other lease backends.
• Scope agent access. Pass placeholders to a command and inject credentials into matching HTTPS requests. An MCP server also exposes selected secrets and command execution.

Providers

Mix providers in the same project. Each provider guide covers authentication, configuration, and reference formats.

Where values live	Providers
Encrypted in your config	age, FIDO2, YubiKey, AWS KMS, Azure KMS, GCP KMS
Cloud and hosted stores	AWS Secrets Manager, AWS Parameter Store, Azure Key Vault, Azure App Configuration, GCP Secret Manager, Vault, Doppler, FOKS, Bitwarden Secrets Manager, Keeper Secrets Manager
Password managers and secret services	1Password, Bitwarden, Infisical, Passwordstate, Proton Pass
Local stores	OS keychain, KeePass, password-store
Non-sensitive configuration	Plaintext defaults

See the provider comparison to choose a storage model. Cloud KMS providers require network access even though their ciphertext lives locally.

Contribute

Start with CONTRIBUTING.md for development setup, tests, and documentation changes. Report bugs in the issue tracker.

Sponsors

Sponsored by

   

View all sponsors

License

MIT