HN Showcase
Back to browse
GitHub Repository

Run any process with secrets from all your backends. No SaaS, no re-encryption, no .env files.

10 starsRust

SecretEnv – Run any process with secrets from all your backends

by techalchemist·May 5, 2026·5 points·8 comments
Visit ProjectView on HN

AI Analysis

●●SolidSolve My Problem

Unifies Vault, AWS SSM, and 1Password into one env var injector without lock-in.

Strengths
  • •Separates secret aliases in repo from backend paths in a central registry.
  • •Supports 14 backends including Vault, AWS SSM, 1Password, and Keeper.
  • •Zero secrets stored on disk; injected only into child process memory.
Weaknesses
  • •Requires managing a separate alias registry alongside existing backends.
  • •Competes with dotenvx and Infisical which offer similar multi-backend support.
Category
Security
Target Audience

DevOps engineers and backend developers managing multi-backend secrets

Similar To

dotenvx · Infisical · envconsul

Post Description

Hi Guys,

I built SecretEnv to help solve one common thing that I have seen at every org, that I have worked at.

We always had more than one password/credential manager. Service tokens maybe in Vault, AWS SSM etc and some team specific service account or temp account credentials being store in another password store such as 1Password or Keeper, there was never one single credential store.

This is where SecretEnv comes in play, it runs any command with secrets injected as env vars, sourced from whatever combination of backend your team already uses.

I am sure there are other tools as well that do a similar thing, which is run a command and inject secret. However SecretEnv does one thing differently.

The key idea is separating two items which are most of the time combined. Think of SecretEnv's resolution structure like an Address Book.

- Your repo gets a secretenv.toml file which has labels in there as values against ENV Vars. These can be literally anything. DB_URL, STRIPE_KEY whatever.

- You have a registry that lives in your backend that you/your company uses. This registry holds the actual paths so the credentials.

- You have a config file on your machine called config.toml that secretenv uses to grab the aliases from secretenv.toml and resolve against registry that lives in your backend.

So imagine if you are a Platform Engineer and need to migrate password stores to different backend.

You can now migrate secrets from AWS to Vault or change the naming conventions in one central place (registry) without devs having to touch their code or update config file.

What this means is if the credential is used by 10, 15 or even 20 repos. All you need to do is update the alias in the registry and all repos pick up the changes.

No need to open PR's, involve dev teams.

The whole idea was abstracting and decoupling the dependency.

The tool currently supports 14 backends already which covers most of the ground.

Would love your feedback and if there is any backends or workflow that this does not cover.

https://github.com/TechAlchemistX/secretenv

Similar Projects

Security●●Solid

Aquaman keeping your OpenClaw secrets safe

The plugin-proxy split is smart: credentials live in a backend (Keychain/1Password/Vault/etc.) and a separate proxy injects auth headers over a UDS so the agent process never handles raw keys. It autosurveys plugin configs and channels to migrate plaintext secrets and even ships a Docker image and CLI for local setups — very practical for anyone already on OpenClaw, though it’s narrowly focused and adds an extra trusted component that deserves an audit.

Niche GemSolve My Problem
tech4242
104mo ago