DEV Community

Cover image for The Day I made production go down, I Built ENVECL
Haripriya Veluchamy
Haripriya Veluchamy

Posted on

The Day I made production go down, I Built ENVECL

#webdev #github #terraform #fastapi

Some outages scream.
Some fail silently.
This one did both and taught me a lesson I won’t forget.

We were migrating Redis. Nothing fancy.
New instance, better specs, same data.

I updated my local .env.
Updated staging.
Tests passed. Everything looked fine.

Then I deleted the old Redis instance.

Production was still pointing to it.

The worst part?
The app didn’t completely go down.

It was slow. Random errors. Inconsistent behavior.
Users started complaining, but nothing was obviously broken.

When I finally checked the production config, I saw it.

Old Redis URL.
Deleted server.
Live production.

What followed was three hours of pure operational pain:

  • manually editing .env files
  • restarting services one by one
  • praying I don’t make it worse

We fixed it. Production came back.
But something else broke—my confidence in how we handled environment variables.

One question kept looping in my head:

Why do we version control code so well, but treat environment variables like tribal knowledge?

That’s where ENVECL started.
Not as a startup idea as frustration.

The Bulb Moment

The real problem wasn’t Redis.

It was config chaos.

Environment variables were everywhere:

  • some in .env files
  • some in Slack
  • some in Google Docs
  • some only in one person’s head

There was no single source of truth.
No history. No visibility.

Ask, “What’s the current production Redis URL?”
You’d get three confident answers all wrong.

With code, Git solves this.
With configs, we were guessing.

ENVECL Is Not a Secrets Manager

I didn’t want to replace secrets management.
I wanted control.

That’s why ENVECL sits on top of HashiCorp Vault.

Vault already does the hard stuff:

  • encryption
  • secure storage
  • access control
  • audit logs

ENVECL’s job is to make Vault usable for real teams without turning everyone into a Vault expert.

Think of it as the missing layer between:

  • humans
  • applications
  • and Vault

How ENVECL Works (Simple on Purpose)

Vault Is the Source of Truth

All environment variables live in Vault KV v2:

secret/
 └── project/
     └── service/
         └── environment
Enter fullscreen mode Exit fullscreen mode

Clear structure.
Every change creates a new version automatically.

That alone would’ve saved my Redis incident.

Thin, Boring Backend (By Design)

The FastAPI backend:

  • authenticates users
  • enforces RBAC
  • talks to Vault

It never stores secrets.

If Vault is down, ENVECL is down and that’s okay.
Vault should be the source of truth.

RBAC That Actually Makes Sense

  • admins manage everything
  • developers see only what they need
  • production access is restricted and auditable

No more “Who changed this?” calls.

Versioning the Thing That Hurt

Every env change:

  • creates a version
  • keeps metadata

This feature exists only because of that outage.

Why I Open Sourced It

This problem isn’t unique to me.

If you’re:

  • too big for .env chaos
  • too small for enterprise security teams

You’re probably living in the same uncomfortable middle ground.

ENVECL is my attempt to fix that using tools we already trust, wrapped in a workflow that actually works.

👉 Repo: https://github.com/Harivelu0/envecl.git

Top comments (0)