Introducing fnox: A secret manager that pairs well with mise

[jdx]

I'm excited to announce fnox – a new secret management tool designed to work seamlessly alongside mise in your development workflow.

While it's brand new, I have labeled it 1.0 since it seems pretty feature complete and given my experience with several experiments with secrets over the years with mise, I think will be a lot more stable than its young age would indicate.

What is fnox?

fnox (think "Fort Knox") is a command-line secret manager that handles encrypted and remote secrets for development, CI/CD, and production environments. It provides a unified interface for managing sensitive data through either local encryption or remote storage backends.

Why fnox?

While mise has built-in secret support (age encryption and sops), these work best for simple, file-based scenarios. For more complex production needs, fnox provides:

• Remote storage in cloud providers (AWS Secrets Manager, Azure Key Vault) or password managers (1Password, Bitwarden)
• Keychain support using local OS cred stores
• Remote encryption using cloud KMS services
• Team collaboration with per-user encryption keys
• Enterprise integration with HashiCorp Vault and other secret stores
• Real-time access without caching security concerns trying to do this in mise would've involved

🚀 Developer-Friendly

• Shell integration: Automatically loads secrets when you cd into directories
• Profile support: Different secret sets for prod, staging, dev
• Simple TOML config: Checked into git (no secrets in the file itself)
• Works offline: When using encryption providers

👥 Team-Ready

• Multiple recipients can decrypt the same secrets
• Each team member can use their own SSH/age keys or leverage KMS
• No shared master passwords

Getting Started

Install fnox with mise:

$ mise use -g fnox
$ fnox --version

Create your first secret:

$ fnox init
$ fnox provider add age --id main --recipients ~/.ssh/id_ed25519.pub
$ fnox secret set API_KEY --value "your-secret-value" --provider main

Use secrets in your workflow:

# Export secrets as environment variables
$ fnox exec -- your-command

# Get a single secret
$ fnox get API_KEY

# Shell integration (auto-load secrets on cd)
$ fnox shell hook

How It Works with mise

fnox and mise work independently but complement each other:

• mise: Manages tools, tasks, and general environment variables
• fnox: Manages sensitive secrets with encryption and remote storage

A typical setup:

mise.toml:

[env]
NODE_ENV = "development"
DATABASE_HOST = "localhost"

[tools]
node = "20"
fnox = "latest"

fnox.toml:

[providers.age]
type = "age"
recipients = ["age1ql3z7..."]

[secrets]
DATABASE_PASSWORD = { provider = "age", value = "AGE-SECRET-KEY..." }
API_KEY = { provider = "1password", ref = "op://dev/api/credential" }

Then use both together:

$ mise x -- fnox x -- npm start

Or you can activate one or the other in your shell to avoid that.

Why Separate Tools?

You might wonder why fnox isn't built into mise. The answer comes down to fundamental architectural constraints:

The Performance Problem: mise reloads its environment frequently (on directory changes, after commands, etc.). If secrets relied on remote calls to services like KMS or 1Password, each reload would require network requests, making mise unacceptably slow.

The Security Tradeoff: Caching could solve the performance issue, but introduces security risks:

• Where do you store encrypted cache files safely?
• Where do you put the encryption keys needed to decrypt those caches?
• How do you prevent cache files from becoming a security vulnerability?

The Architecture Challenge: Making mise skip reloading certain env vars would require a major architectural overhaul—a change that would complicate the codebase significantly.

By creating fnox as a separate tool with its own shell integration, we avoid these problems entirely. Each tool can focus on what it does best:

• mise: Fast environment management with aggressive caching
• fnox: Secure secret management with real-time access to remote providers

Note: For more context on this architectural decision, see the vaults/secrets management discussion.

What's going to happen to mise secrets?

They're still marked as experimental so the future is technically up in the air. That said, mise does work well for age/sops encryption so I think it could probably come out of experimental. For now, I don't have plans to introduce remote secret backends like fnox provides.

Learn More

• GitHub: https://github.com/jdx/fnox
• Documentation: https://github.com/jdx/fnox#readme
• mise Registry: Now available as mise use fnox

[domenkozar]

Since it's a verbatim copy of https://secretspec.dev, any chance of giving attribution?

[jdx]

it's not?

[mkroman]

Both seem adamant to use LLMs. And feature-wise they seem pretty identical. I really hope you didn't use it for the security-sensitive parts.

[drcongo]

I have to ask, do you ever sleep?

[jdx]

this wasn't that hard, I basically just pointed an llm to the existing secrets functionality in mise and it was able to make it in a new place. It took me longer to setup that secret stuff than it did to write fnox.