Why I Built nevr-env — And Why process.env Deserves Better

I got tired of crashing apps, leaked secrets, and copy-pasting .env files on Slack. So I built an environment lifecycle framework.

Every developer has that moment.

You deploy on Friday. CI passes. You go home feeling productive.

Then the ping comes: "App is crashing in production."

The culprit? DATABASE_URL was never set. Your app accessed process.env.DATABASE_URL, got undefined, and silently passed it as a connection string. Postgres didn't appreciate that.

I've hit this exact bug more times than I want to admit. And every time, the fix was the same: add another line to .env.example, hope your teammates read the README, and move on.

I got tired of hoping. So I built nevr-env.

What's Actually Wrong With .env Files?

Nothing — as a concept. Environment variables are the right way to configure apps. The problem is the tooling around them:

1. No validation at startup — process.env.PORT returns string | undefined. If you forget PORT, your server silently listens on undefined.




2. No type safety — process.env.ENABLE_CACHE is "true" (a string), not true (a boolean). Every developer writes their own parsing.




3. Secret sprawl — Your team shares secrets via Slack DMs, Google Docs, or worse. .env.example is always outdated.




4. Boilerplate everywhere — Every new project: copy the Zod schemas, write the same DATABASE_URL: z.string().url(), same PORT: z.coerce.number().

The t3-env Gap

t3-env was a step forward. Type-safe env validation with Zod. I used it. I liked it.

But as my projects grew, the gaps showed:

// Every. Single. Project.

export const env = createEnv({

  server: {

    DATABASE_URL: z.string().url(),

    REDIS_URL: z.string().url(),

    STRIPE_SECRET_KEY: z.string().startsWith("sk_"),

    STRIPE_WEBHOOK_SECRET: z.string().startsWith("whsec_"),

    OPENAI_API_KEY: z.string().startsWith("sk-"),

    RESEND_API_KEY: z.string().startsWith("re_"),

    // ... 20 more lines of the same patterns

  },

});

I was writing the same schemas across 8 projects. When Stripe changed their key format, I had to update all of them.

And when a new teammate joined? They'd clone the repo, run npm run dev, see a wall of validation errors, and spend 30 minutes figuring out what goes where.

So I Built nevr-env

nevr-env is an environment lifecycle framework. Not just validation — the entire lifecycle from setup to production monitoring.

Here's what the same code looks like:

import { createEnv } from "nevr-env";

import { postgres } from "nevr-env/plugins/postgres";

import { stripe } from "nevr-env/plugins/stripe";

import { openai } from "nevr-env/plugins/openai";

import { z } from "zod";



export const env = createEnv({

  server: {

    NODE_ENV: z.enum(["development", "production", "test"]),

    API_SECRET: z.string().min(10),

  },

  plugins: [

    postgres(),

    stripe(),

    openai(),

  ],

});

3 plugins replace 15+ lines of manual schemas. Each plugin knows the correct format, provides proper validation, and even includes auto-discovery — if you have a Postgres container running on Docker, the plugin detects it.

The Three Features That Changed Everything

1. Interactive Fix Wizard

When a new developer runs your app with missing variables:

$ npx nevr-env fix

Instead of a wall of errors, they get an interactive wizard:

? DATABASE_URL is missing

  This is: PostgreSQL connection URL

  Format: postgresql://user:pass@host:port/db

  > Paste your value: █

Onboarding time went from "ask someone on Slack" to "run one command."

2. Encrypted Vault

This is the feature I'm most proud of.

# Generate a key (once per team)

npx nevr-env vault keygen



# Encrypt your .env into a vault file

npx nevr-env vault push

# Creates .nevr-env.vault (safe to commit to git!)



# New teammate clones repo and pulls

npx nevr-env vault pull

# Decrypts vault → creates .env

The vault file uses AES-256-GCM encryption with PBKDF2 600K iteration key derivation. It's safe to commit to git. The encryption key never touches your repo.

No more Slack DMs. No more "hey can you send me the .env?" No more paid secret management SaaS for small teams.

3. Secret Scanning

$ npx nevr-env scan



  Found 2 secrets in codebase:



  CRITICAL  src/config.ts:14  AWS Access Key (AKIA...)

  HIGH      lib/api.ts:8      Stripe Secret Key (sk_live_...)

This runs in CI and catches secrets before they hit your git history. Built-in, no extra tools needed.

13 Plugins and Counting

Every plugin encapsulates the knowledge of how a service works:

And you can create your own:

import { createPlugin } from "nevr-env";

import { z } from "zod";



export const myService = createPlugin({

  name: "my-service",

  schema: {

    MY_API_KEY: z.string().min(1),

    MY_API_URL: z.string().url(),

  },

});

The Full CLI

nevr-env ships with 12 CLI commands:

Try It

pnpm add nevr-env zod

npx nevr-env init

The init wizard detects your framework, finds running services, and generates a complete configuration.

GitHub: github.com/nevr-ts/nevr-env

npm: npmjs.com/package/nevr-env

Docs: [https://nevr-ts.github.io/nevr-env/)

If you've ever lost production time to a missing env var, I'd love to hear your story. And if nevr-env saves you from that — a star on GitHub would mean the world.

Built by Yalelet Dessalegn as part of the nevr-ts ecosystem.