← All workCase study 14

envy

A near-zero-dependency CLI that turns .env files from tribal knowledge into a schema a team can validate, audit and generate types from.

Type

Developer Tool

Status

Shipped

Context

Open source · published on npm

Period

2026

Source

Public

(01) Overview

Every Node.js project has the same .env problems. Someone adds a variable and forgets to tell the team, staging breaks because a variable was renamed, and a new developer clones the repo with no idea what belongs in .env. envy fixes that with a schema format describing every environment variable an application uses, then validates, audits and code-generates against it — including scanning the codebase for process.env access that was never declared.

(02) Architecture

.env.schema format with types, required/optional, format validators and modifiers · codebase audit for undeclared process.env usage including destructured and bracket-notation access · typed env.ts codegen that validates on import · team defaults sync that never overwrites local values · published on npm

(03) What was built
  1. 01A .env.schema format describing every variable an app needs: type, required or optional, format validators (postgresql-url, redis-url, jwt-secret, hex-color, semver and more), plus modifiers like default, min/max and enum.
  2. 02`envy audit` scans the entire codebase for process.env usage — including destructured and bracket-notation access — and flags anything used but not declared.
  3. 03`envy generate` produces a fully-typed src/env.ts that validates on import, so the app refuses to start with a missing required variable rather than failing opaquely on first use.
  4. 04`envy sync` shares non-secret team defaults through a committed .env.team.json without ever overwriting a value a developer already has set locally.
  5. 05Near-zero runtime dependencies, fully tested, and published to npm.
(04) Stack

TypeScript / Node.js / npm

Next case study

serpcraft

→