DEV Community

Cover image for Built envx-cli Because Managing Envs Shouldn't Be This Hard 😤
Rahul Retnan
Rahul Retnan

Posted on

Built envx-cli Because Managing Envs Shouldn't Be This Hard 😤

#dotenv #devtool #node #envx

TL;DR: Got frustrated with existing env tools, spent a weekend with Claude Sonnet 4, and built envx-cli. Now managing environment variables across monorepos or any type of project repos is actually enjoyable.

The Pain Was Real

Managing environment variables has always been challenging. Like, seriously challenging.

I started with the classic approach - GPG encryption with shell scripts and Makefiles. Works, but feels like I'm living in 2010. Then I heard about dotenvx and thought "finally, someone gets it!"

Dotenvx is "a better dotenv–from the creator of dotenv" and honestly, it's amazing. Solves problems for most devs perfectly. But here's where my specific setup became a nightmare:

The Problem: I work with Nx monorepos. Multiple services, different stages (dev/staging/prod), and dotenvx was overriding keys and creating a single .env.keys file.

This meant:

  • Creating per-service folders 📁
  • Writing tons of custom scripts 📝
  • Fighting the tool instead of using it 😤

Don't get me wrong - dotenvx is brilliant! It just wasn't designed for my specific monorepo + multi-service Docker setup.

Then I looked at Infisical. Another great solution, but felt like overkill for smaller projects. The self-hosting overhead wasn't worth it for most of my use cases.

The "Why Not?" Moment

After another afternoon wrestling with environment configurations, I had that classic developer epiphany:

"How hard could it be to build this myself?"

The package name came instantly: "envx". Clean, purposeful, memorable.

checks npm

Already taken. Of course. 🤦‍♂️

"envx-cli" it is!

The Weekend Build Setup

IDE Choice: Cursor felt like overkill, so I went with Zed + GitHub Copilot API.

Holy moly, what an awesome combination! Fast, responsive, just enough AI assistance without the heavyweight overhead. Sometimes you don't need the rocket launcher.

The Prompt Strategy: Instead of traditional planning, I invested time in crafting one detailed prompt with:

  • All feature requirements
  • How I wanted it to behave
  • Multi-service and monorepo support
  • .envrc compatibility (crucial!, Since Most of my project relies on it)

Tech Stack (mentioned these to the AI since I had experience):

  • commander - CLI framework excellence
  • inquirer - Interactive prompts that don't suck
  • shelljs - Cross-platform shell operations
  • zod - TypeScript validation that actually works

The Magic Happened

After a few minutes (seriously!), it was there. The whole thing. Working.

My first thought: "I should have done this sooner."

The Development Process:

  1. Prompt 1: Core project with all features
  2. Prompt 2: Bug fixes and comprehensive test suite
  3. Prompt 3: Additional features and polish

That's it. Three prompts with Claude Sonnet 4 (both thinking + non-thinking models).

Next steps: CI setup, GitHub push, NPM publish. Done.

What envx-cli Actually Does

Let me show you why this tool is different:

The Core Innovation: GPG + .envrc Integration 

# Initialize in your Nx monorepo
envx init

# Create environment files
envx create -e development
envx create -e production

# Set up encryption secrets (integrates with .envrc)
envx interactive

# Encrypt sensitive environments
envx encrypt -e production --overwrite

# The magic: copy to .env for any service with the project
envx copy -e production --all
Enter fullscreen mode Exit fullscreen mode

Why This Matters for Nx Monorepos

Before envx-cli:

# Managing multiple services was painful
apps/
├── api/.env.dev, .env.prod.gpg, custom-scripts
├── web/.env.dev, .env.prod.gpg, more-scripts
└── worker/.env.dev, .env.prod.gpg, even-more-scripts
Enter fullscreen mode Exit fullscreen mode

With envx-cli:

# From project root, manage everything

# Decrypts and copy the `.env.production` to `.env` with in each Service Folders
envx copy -e production --all

# Encrypts ALL environments
envx encrypt --all

# Decrypts ALL when needed
envx decrypt --all
Enter fullscreen mode Exit fullscreen mode

One .envrc file in the root manages all encryption secrets. No per-service complexity.

Real-World Workflow

Development:

envx copy -e development --all
npm run dev
Enter fullscreen mode Exit fullscreen mode

Staging Deployment:

envx copy -e staging --all --overwrite
docker-compose -f docker-compose.staging.yml up
Enter fullscreen mode Exit fullscreen mode

Production:

envx copy -e production --all --overwrite
docker-compose up -d
Enter fullscreen mode Exit fullscreen mode

The .envrc Prerequisite

One key requirement: you need .envrc integration. If you're using direnv (and you should be), envx-cli plays perfectly with your existing workflow.

The .envrc file stores your encryption secrets:

export DEVELOPMENT_SECRET="your-dev-secret"
export STAGING_SECRET="your-staging-secret"  
export PRODUCTION_SECRET="your-prod-secret"
Enter fullscreen mode Exit fullscreen mode

Security That Actually Works

Unlike tools that reinvent encryption, envx-cli uses GPG - the gold standard. Your secrets are as secure as your GPG setup.

Best practices built-in:

  • ✅ Commit encrypted .gpg files
  • ✅ Never commit .envrc (contains secrets)
  • ✅ Strong encryption by default
  • ✅ Security status checking with envx status

Smart .gitignore handling:

# Environment files
.env.*
!.env.example
!*.gpg        # Encrypted files are safe to commit

# EnvX secrets  
.envrc        # Never commit secrets
Enter fullscreen mode Exit fullscreen mode

The AI Development Experience

The most surprising part? How well Claude understood my requirements. By providing clear, detailed specifications upfront, the generated code was production-ready.

My validation process:

  • Manual code review (always!)
  • Added comprehensive test suite
  • Real-world testing across multiple projects
  • Security audit of GPG integration

Key lesson: AI is incredibly powerful, but you still need to validate everything. Don't just trust - verify.

Why This Matters in 2025

The barrier to creating custom developer tools has never been lower. When existing solutions don't fit your specific workflow, building your own is now a viable weekend project.

The approach:

  1. Clear requirements upfront (better prompts = better code)
  2. Choose proven technologies (boring tech works better with AI)
  3. Validate everything (AI is smart, not infallible)
  4. Solve your own problem first (then share with community)

Get Started

Ready to simplify your environment management?

# Install globally
npm install -g envx-cli

# Initialize in your project  
envx init

# Create and encrypt environments
envx create -e production
envx interactive  # Set up secrets
envx encrypt -e production

# Use in development
envx copy -e development
Enter fullscreen mode Exit fullscreen mode

Links:

The Real Message

There are tons of AI tools out there. If you don't find the right tool or it's not meeting your specific requirements, go build it yourself. Vibe code the whole thing!

Just make sure the AI isn't doing any funny business. In my case, I reviewed every line and added separate test scripts to catch issues.

Which model? No secrets - Claude Sonnet 4 (both thinking + non-thinking). Three prompts total.

The whole point: when existing tools don't fit your workflow, the solution might be a weekend away.

Happy Vibe Coding! 🚀

Working with Monorepos and environment management headaches? Give envx-cli a try and let me know how it works for your setup. Contributions welcome!

Top comments (0)