I Built CrowEnv: An Encrypted Replacement for .env Files

Yogesh Singh — Sat, 07 Mar 2026 00:19:05 +0000

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:

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

With CrowEnv, the flow becomes:

initialize CrowEnv
generate a master key
encrypt .env into .cenv
delete the plain .env
commit .cenv
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.

I built flash-pkg — fix slow pip/npm installs on slow internet

Yogesh Singh — Sat, 07 Mar 2026 00:11:03 +0000

Many developers in Asia struggle with slow dependency installs.

I built flash-pkg to solve this problem.

flash-pkg pre-caches heavy dependencies like torch, transformers, React, Next.js so new projects start instantly.

Key features:
• 10–100x faster installs
• Works on Linux, macOS, Windows
• Shareable compressed cache

GitHub:
https://github.com/Yogesh1290/flash-pkg

DEV Community: Yogesh Singh