Show HN: From dotenv to dotenvx – better config management

Original Article ↗ Hacker News Discussion ↗

Scope and purpose of dotenvx

  • Seen as an evolution of dotenv: CLI tool to load multiple .env files, handle per-environment configs, and optionally encrypt individual values.
  • Some argue this could have been a backward‑compatible extension of dotenv instead of a new project; others see the split as marketing and company-building.
  • Not Node-specific; positions itself as a generic process launcher with (optionally encrypted) env vars.

.env files and env vars in production

  • Strong disagreement over use of .env in prod:
    • Many argue .env should be dev-only and never exist on production servers.
    • Others note it’s common in VPS / real-world setups and they “just live with it.”
  • Broader critique that env vars themselves are poor for secrets: they leak via logs, debugging, child processes, and /proc/*/environ.

Secrets management & security model

  • Advocates: encrypting .env values and committing them is a DX win and “good enough” for many teams; reduces risk of plain-text leaks and fits GitOps workflows.
  • Critics: encryption without robust key management creates an illusion of security; if the private key leaks, everything is exposed.
  • Concerns about key rotation, single .env.keys files, and where to store the decryption key (often ends up in the same threat domain).

Encrypted secrets in git

  • Supporters compare dotenvx-style encryption to tools like sealed-secrets, sops, or custom schemes; find it practical for small teams.
  • Opponents insist secrets should live in vaults or infrastructure-native secret stores and never in VCS, even encrypted.
  • Risk highlighted: rollbacks to older commits with outdated secrets; long-lived keys embedded in history.

Alternatives and comparisons

  • Mentioned alternatives: sops, HashiCorp Vault, cloud secret managers (AWS, Azure, GCP), SecureStore, sealed-secrets, foreman, mise, dmno, phase.dev, others.
  • Some prefer simple envdir-style folders, gpg-encrypted files, or password managers plus local injection.

Design and implementation critiques

  • Worry about increased dependency surface vs original dotenv’s zero deps and Node’s built-in --env-file support.
  • Concerns about command interpolation, inconsistent dotenv dialects, and potential security pitfalls.
  • Some dislike that the tool can contact a “hub” over HTTP; would prefer a fully offline binary (often in Rust/Go).