SecretEnv gets rid of the .env files entirely. Your project lists what it needs by nickname, the actual secrets live in whatever backends your team already uses. Change backend? One line and every repo picks it up.
Both work with any language.
They could actually compose together, varlock can call secretenv to pull from the backends and validate on the top. :)
We piggyback on .env files with a new DSL rather than introducing a new file.
Using plugins that register new functions, you can fetch from many different backends (15 and growing). The main difference if I understand correctly is that the wiring of vars to where those things live does live in committed code, but is totally declarative and safe. It's also incredibly flexible since functions can be written to make things idiomatic for that backend. Keeping that within git makes sense to us, as you ideally want deployments to be immutable.
The other benefit is this gives you a way to manage both sensitive and non-sensitive config - with a single source of truth for validation, types, docs.
I had evaluated fnox. However you have a dependency of encryption/decryption.
So imagine the use case where you need to roll out a password change to 10 repos or offboard an engineer from the team.
In either case, the touch point now becomes 10 repos which need to be co-ordinated against.
Now imagine doing this at scale, you need to migrate password stores entirely. Not that it happens often, however I have been at start-ups where we moved from one cloud provider to another because we gained better discounts on contracts. The password store migration then would be an effort vs just updating 1 line in registry and it resolves.
Similarly user offboarding is handled by IAM permission as well, as soon as the user access is revoked the secret resolution is gone.
Thank you for bringing up fnox and mise. This was something I had evaluated and even written about in the security threat model. :)
You SSH into your jumpbox, clone your dotfiles, fireup tmux and something is off.
Your status bar is still the default green and vim-tmux-navigator isn't working. You spend a couple minutes before you realize you forgot to clone TPM. o_O
It doesn't happen every time, but it has happened to me one too many times, and even when you do remember, there is no guarantee the plugin versions you get today match what you had last month.
TPM installs plugins, that's it. No Lock file, no version pinning, no reproducibility.
Muxforge is a single Go binary that manages tmux plugins the way you'd expect in 2026. Lock file for reproducibility, one-command migration from TPM, and a managed block in your tmux.conf that keeps plugin declarations clean without touching the rest of your config.
Works with stow and dotfile managers, the lock file is designed to live in version control.
v0.4.0 went up yesterday. MIT licensed. Would love feedback from anyone who's felt this pain.
reply