Cool, I checked it out and must say varlock's solid, but it's solving different problem.

Varlock makes .env files smarter (validation, types, editor autocomplete, Next.js/Vite hooks).

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.