Show HN: KeyEnv – manage team secrets without scattered .env files(keyenv.dev)
keyenv.dev
Show HN: KeyEnv – manage team secrets without scattered .env files
https://keyenv.dev/
4 comments
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
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
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.
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.
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
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
Appreciate the pushback — you clearly know this space well.
On open source: no, KeyEnv is not open source. That's a real trade-off and I should have said so directly.
On pricing math: you're right in that scenario. For 10 devs with 10 total secrets, AWS SM is dramatically cheaper. Our pricing makes more sense when teams have dozens of secrets per environment across multiple projects (dev/staging/prod) — where the per-user flat rate becomes predictable. But I take the point that the break-even is higher than I'd like.
On hyperscaler friction: fair, it's gotten much better. The main gap we see is local dev DX — injecting secrets into `npm start` or `docker compose up` without writing files. But you could wrap that around SM too.
Honest feedback helps. Thanks.
On open source: no, KeyEnv is not open source. That's a real trade-off and I should have said so directly.
On pricing math: you're right in that scenario. For 10 devs with 10 total secrets, AWS SM is dramatically cheaper. Our pricing makes more sense when teams have dozens of secrets per environment across multiple projects (dev/staging/prod) — where the per-user flat rate becomes predictable. But I take the point that the break-even is higher than I'd like.
On hyperscaler friction: fair, it's gotten much better. The main gap we see is local dev DX — injecting secrets into `npm start` or `docker compose up` without writing files. But you could wrap that around SM too.
Honest feedback helps. Thanks.
- 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.