I Built CrowEnv: An Encrypted Replacement for .env Files

# webdev# opensource# security# typescript
I Built CrowEnv: An Encrypted Replacement for .env FilesYogesh Singh

For years, developers have been told the same thing: use .env add it to .gitignore never commit...

For years, developers have been told the same thing:

  • use .env
  • add it to .gitignore
  • never commit secrets
  • hope nobody leaks anything

That workflow is everywhere.

It is also fragile.

Plain .env files were convenient, but they were never designed to be a real security boundary. The modern developer workflow still depends on humans remembering not to commit sensitive values, not to expose build logs, not to leak backups, and not to misconfigure deployments.

I wanted something better.

So I built CrowEnv — a system that replaces insecure plain .env files with .cenv, an encrypted format for secrets that can be committed to Git safely.

GitHub repo:
https://github.com/Yogesh1290/crowenv

The problem with .env

The problem is not that .env is bad at configuration.

The problem is that .env is plain text.

That means the moment a secret enters a normal .env file, the safety of that secret depends on:

  • whether .gitignore was correct
  • whether a teammate accidentally committed it
  • whether a backup, ZIP, log, or screenshot exposed it
  • whether a public file path made it reachable
  • whether old Git history still contains it

In other words, the standard workflow is not secure by design. It is secure only if nobody makes a mistake.

That is not a great model for real teams, real repos, and real deployments.

What CrowEnv does

CrowEnv introduces a different model:

  • keep secrets encrypted by default
  • store them in a .cenv file
  • commit .cenv to Git
  • keep only the master key secret

Instead of saying “never commit secrets,” CrowEnv changes the workflow to:

commit encrypted secrets safely, keep the decryption key separate

That gives developers something the traditional .env convention does not:
a secrets file that is meant to survive inside real Git workflows.

According to the repo README, CrowEnv’s .cenv format uses AES-256-GCM encryption, with PBKDF2-HMAC-SHA256 key derivation at 600,000 iterations, and includes integrity protection through the GCM authentication tag. oai_citation:1‡GitHub

Why I called it CrowEnv

Crows are smart.
They hide valuable things.
They remember where they put them.

That idea matched the product perfectly.

A .env file leaves treasure in the open.
A .cenv file hides it properly.

That is the idea behind CrowEnv:
smart secrets, hidden safely, but still usable in real workflows.

How the workflow changes

With a normal .env setup, the flow is usually:

  1. create .env
  2. fill it with API keys, DB passwords, tokens
  3. add .env to .gitignore
  4. hope it never leaks

With CrowEnv, the flow becomes:

  1. initialize CrowEnv
  2. generate a master key
  3. encrypt .env into .cenv
  4. delete the plain .env
  5. commit .cenv
  6. decrypt or load secrets only when needed

That means the file inside your repository is no longer plain text.

The repo shows this quick-start flow:

  • crowenv init
  • crowenv generate-key
  • set CENV_MASTER_KEY
  • crowenv encrypt
  • delete .env
  • commit .cenv safely oai_citation:2‡GitHub

This is the part that makes CrowEnv interesting to me:
it does not just say “manage env files better.”
It says:
stop storing secrets in plaintext in the first place.

What CrowEnv includes

One thing I wanted was for this not to be just a single CLI hack.

The repo is structured as a broader ecosystem:

  • Node.js CLI
  • Python package
  • Go CLI
  • Rust CLI
  • VS Code extension
  • Docker and Kubernetes deployment examples
  • CI scripts
  • a formal spec for the .cenv format oai_citation:3‡GitHub

That matters because secrets handling is not a single-language problem.

A real solution should work across:

  • app development
  • local machines
  • CI/CD
  • containers
  • multiple programming languages
  • editors and tooling

CrowEnv is designed with that larger ecosystem in mind.

Core commands

The base commands in the repo are straightforward:

  • crowenv init
  • crowenv generate-key
  • crowenv encrypt
  • crowenv decrypt
  • crowenv load
  • crowenv verify oai_citation:4‡GitHub

That gives a pretty clean lifecycle:

  • initialize the project
  • create a key
  • encrypt secrets
  • load them into the process environment when needed
  • verify file integrity

For developer experience, that is important.
Security tools fail fast when they become painful to use.

The .cenv format

CrowEnv is not just “encrypt the file somehow.”

The repo includes a defined format with versioning and structure, including:

  • a version field
  • a random salt
  • encrypted payload data

The README also documents the cryptographic pieces behind it:

  • AES-256-GCM
  • PBKDF2-HMAC-SHA256
  • 600,000 iterations
  • random nonce
  • authentication tag for tamper detection oai_citation:5‡GitHub

That makes the project feel more like a protocol and less like a throwaway wrapper around .env.

This part is important because if a tool wants adoption, it cannot just be “my personal format.”
It needs a spec, consistency, and portability.

CrowEnv already moves in that direction.

What makes CrowEnv different from “just use a secret manager”

A lot of people will ask:
why not just use Vault, AWS Secrets Manager, Doppler, 1Password Secrets, or GitHub Actions secrets?

Those tools are useful.
But they solve a somewhat different problem.

CrowEnv is appealing in situations where developers want:

  • a file-based workflow
  • local-first usage
  • Git-friendly collaboration
  • multi-language portability
  • something lightweight and easy to bootstrap

In other words, CrowEnv is not trying to replace every enterprise secret platform.
It is trying to improve the very common, very old, very fragile .env workflow.

That is a big difference.

Who I think this is for

I think CrowEnv is most useful for:

  • indie hackers
  • open-source maintainers
  • small teams
  • self-hosters
  • developers shipping across multiple stacks
  • people tired of secret leaks caused by plain .env files

If your workflow still relies on “please don’t commit .env by mistake,” then you are depending on behavior instead of design.

CrowEnv changes the design.

The bigger idea

The bigger idea behind CrowEnv is simple:

plaintext secrets should not be the default developer experience anymore.

That old convention survived because it was easy, not because it was good.

CrowEnv tries to keep the ease of file-based configuration while removing the most dangerous assumption:
that secrets should sit in raw text and be protected mostly by habit.

That is why I built it.

Not to make .env slightly nicer.

To make .env unnecessary.

Try it

Repo:
https://github.com/Yogesh1290/crowenv

If this idea resonates with you, I would love feedback on:

  • the .cenv format
  • developer workflow
  • CLI ergonomics
  • editor integration
  • multi-language support
  • CI/CD use cases

I’m especially interested in making CrowEnv feel like a serious modern replacement for plaintext env files — not just another wrapper around them.