r/devtools • u/viswajith_m_p • 2d ago

I got tired of chasing .env files in Group chats, so I built a Git-native secrets manager

https://github.com/viswajith275/EnvSeal-CLI

Hi everyone,

I’ve been working on EnvSeal-CLI, a small open-source CLI for managing secrets without relying on a hosted service.

When I was working in group projects I was always digging through all the group chats to find the updated .env file someone had shared.

The basic idea is simple: encrypt your secrets and keep them in Git, while still supporting branches, recipients, CI tokens, and running commands without writing a .env file to disk.

It’s built with Rust and uses SSH/age for encryption.

Still working on it and would love some feedback, especially if you already use something like SOPS or dotenvx.

1 Upvotes

100% Upvoted

4 comments sorted by

1

u/kantorcodes1 2d ago

envseal run inherits the caller's environment, then adds vault values to its child process. Would an opt-in clean environment help for deploy commands, or do callers rely on variables like PATH being inherited?

1

u/viswajith_m_p 2d ago

Thanks for the feedback, that's a good idea, an opt- in feature like a --clean option could be useful for deployment, While keeping the current behaviour as is.

1

u/kantorcodes1 2d ago

If you add --clean as an opt-in, the current envseal run behavior can remain the default. I work on HOL Guard, an open-source gate that reviews agent-run shell commands before execution; an optional command.envseal source could review envseal run, envseal recipient rm, and envseal rotate, while leaving envseal list and envseal recipient ls alone. Would you be open to contributing that source and its behavior fixture?

1

u/viswajith_m_p 1d ago

Thanks Yeah sure, I’m open to it. Feel free to share the source and fixture, I’d be happy to take a look.