Show HN: KeyEnv – manage team secrets without scattered .env files (opens in new tab)

(keyenv.dev)

1 pointsivannovazzi29d ago4 comments

Tired of .env files getting out of sync across team members and environments? KeyEnv is a CLI-first secrets manager that replaces scattered .env files with a secure, encrypted store.

- Pull secrets with a single command: keyenv pull - Secrets are AES-256-GCM encrypted at rest - Per-project, per-environment scoping (dev/staging/prod) - Team access controls + full audit trail - Works with existing apps that read from environment variables — zero code changes

The problem we kept running into: teams share secrets over Slack, check in .env.example files with real values, or have 5 different versions of the same key floating around. KeyEnv eliminates the category.

We'd love feedback, especially from teams dealing with microservices or multi-environment setups.

4 comments

verdverm29d ago

We already have open source tools for this and hyperscaler options in the cloud.

Is yours open source? Why would I choose this over the options I already have?

Your pricing is far more expensive, we pay per secret, not user, and at those prices we could store orders of magnitude more secrets than we do for those prices

ivannovazziOP29d ago

Fair question. A few differentiators:

On open source: tools like Vault, Doppler, or Infisical are excellent but require setup, maintenance, and infra (or their hosted tier). KeyEnv's value prop is zero infra — install the CLI, run `keyenv run -- your-command`, done. For small teams that don't want to manage secrets infra, it's faster.

On hyperscalers: AWS Secrets Manager / GCP Secret Manager work well at scale but have per-secret pricing that adds up, and the DX friction is non-trivial (IAM, SDK calls, region config). We're optimized for developer teams who want CLI-first access without cloud-specific lock-in.

On pricing: the per-user model is intentional — it stays predictable as the secret count grows. You're right that at very high secret counts hyperscalers win on cost. We're not competing there; we're competing on simplicity for teams of 2–20 devs.

Not a fit for every team — just trying to make the tradeoffs honest.

verdverm28d ago

you are wrong on every point

On Open Source: you deflect from the actual question to talk about cloud hosting, which they also have

On hyperscalers: very little friction, cloud lockin is not true

On pricing: your calculation is backwards, for a team of 10 with 10 secrets, yours costs 48x, break even does not happen until I have 48 secrets per developer, I don't know anyone near that

Context: this is one thing I get paid to do

1 more reply

j / k navigate · click thread line to collapse