DEV Community: Shahnoor_Mujawar

dotenv Hasn't Evolved in 10 Years — So I Built Something Better

Shahnoor_Mujawar — Wed, 04 Mar 2026 09:17:14 +0000

If you've built a Node.js application, you've probably used dotenv.

The typical setup looks like this:

1️⃣ Install dotenv
2️⃣ Create a .env file
3️⃣ Access values with process.env

import "dotenv/config"

const db = process.env.DATABASE_URL

For years, this workflow has worked fine.

But once applications grow, things start to break down.

The Hidden Problems with dotenv

As projects scale, teams often run into issues like:

• missing environment variables
• runtime crashes from bad configuration
• manually sharing .env files between developers
• no validation or type safety

dotenv solves loading environment variables.

But it doesn't solve managing them.

The Typical dotenv Workflow

A typical .env file might look like this:

DATABASE_URL=postgres://localhost:5432/app
JWT_SECRET=mysecret
PORT=3000

Then inside your application:

import "dotenv/config"

const port = process.env.PORT

This works — but it also means:

everything is a string
nothing is validated
errors happen at runtime

What I Wanted Instead

I started thinking about what a modern environment workflow should look like.

Ideally it should have:

• validation
• type safety
• a CLI workflow
• a better way to share variables across teams

So I built PushEnv.

dotenv vs PushEnv

Feature	dotenv	PushEnv
Simple env loading	✓	✓
Validation	✗	✓
Type safety	✗	✓
CLI workflow	✗	✓
Team sync	✗	✓

dotenv is still great for small projects.

But modern applications often need stronger configuration management.

A Better Approach

With PushEnv, environment variables are defined using a schema.

Example:

import { z } from "zod"

export const envSchema = {
  DATABASE_URL: z.string().url(),
  PORT: z.number(),
  JWT_SECRET: z.string()
}

Now invalid configurations are caught before the application even starts.

CLI Workflow

PushEnv also introduces a CLI workflow for managing environment variables.

pushenv init
pushenv push
pushenv pull

This makes it easier to synchronize environment variables across teams.

When Should You Use Each?

Use dotenv if:

• you're building a quick prototype
• you're working on a small personal project

PushEnv works best for:

• production applications
• teams collaborating on projects
• applications that require configuration validation

Try PushEnv

PushEnv is open source and available on GitHub.

You can try it in seconds:

npm install pushenv

pushenv init
pushenv push

GitHub: https://github.com/shahnoormujawar/pushenv

If you're interested in improving environment variable management, I'd love to hear your feedback.

🚀 Startup Engineering Isn’t About Code — It’s About Tradeoffs

Shahnoor_Mujawar — Wed, 14 Jan 2026 04:59:53 +0000

Every startup engineer knows this moment.

The code isn’t perfect.The architecture isn’t “clean.”Future-you is already planning the refactor.

And yet… you ship.

Because in a startup, engineering isn’t about writing beautiful code.It’s about making smart tradeoffs that keep the business alive.

Speed vs stability.Shipping vs perfection.Scalability vs simplicity.

The “right” choice isn’t the prettiest one —It’s the one that helps you survive.

And the data agrees:70% of startup failures come from premature scaling or over-engineering, not just bad ideas.

🎯 The Problem With “Perfect” Engineering

Most tutorials show clean, ideal systems.

Infinite time.Big teams.Perfect roadmaps.

Real startups don’t look like that.

You’re shipping in chaos.One engineer owns frontend, backend, and DevOps.The roadmap changes every quarter.

And perfection slows you down.

One analysis of 200+ failed SaaS startups found over-engineering delayed launches by 6–12 months, while faster competitors captured 40% more early market share.

Meanwhile, Basecamp runs a simple Rails monolith serving 3 million users.

No hype.No rewrites.Just shipping.

“Good enough” beats “perfect” every time.

⚡ The Tradeoffs That Actually Matter

Startup engineers don’t live in theory.They live in production.

Here are the real decisions that shape outcomes:

🚀 Speed vs Stability

WhatsApp scaled to 450M users with just 32 engineers on an Erlang monolith.They handled 50B messages/day using caching — not heavy infrastructure.

On the other hand, early microservices adopters saw 3× slower deploy times after scaling.

Lesson:Ship fast. Stabilize after PMF.

🛠 Shipping vs Perfecting

Stack Overflow scaled a C# monolith to 250M+ monthly users for over 10 years without microservices.

A Reddit thread with 500+ makers showed 80% regretted over-polishing instead of launching earlier.

Lesson:MVPs beat perfect betas.

📈 Scalability vs Simplicity

Basecamp hit $100M ARR on a single Rails app with a 50-person team.

Twitter’s early monolith caused the FAIL Whale —But that same simplicity helped them pivot fast.

Microservices add 2–5× operational overhead.

Lesson:Monoliths first. Split when it hurts.

🧼 Purity vs Survival

One CTO stuck with a monolith at 1M users and saved 6 months of engineering time.

Another startup let technical debt grow —Bug rates tripled, velocity halved, and the company collapsed.

Stack Overflow didn’t chase “clean architecture.”They focused on database partitioning and kept 99.99% uptime.

Lesson:Measure debt by velocity, not aesthetics.

🧠 What Great Startup Engineers Actually Do

They think like operators.

They ask:“Will this survive 10× traffic?”“Does this ship faster?”“Can we undo it later?”

They document tradeoffs in PRs:“Cron over Kafka — 90% cheaper ops for now.”

One unicorn engineer avoided a $500K rewrite by proving their monolith shipped features 5× faster.

Teams shipping weekly outperform quarterly teams by 300% in feature velocity.

Not because they’re smarter —Because they move.

🔥 A Hard Lesson From the Trenches

I once split a side project into 5 microservices.

Deploys went from 5 minutes to 2 hours.One user flow touched 7 repos.Momentum died.

We switched back to a monolith.

We shipped 10× faster the next week.

Later, I watched a SaaS founder ride “ship fast” shortcuts into a wall.

By month 19:Features took 3× longer.Bugs exploded.Trust disappeared.

Now I judge every decision by:

Reversibility — Can we undo this fast?
Impact horizon — Who benefits now vs later?

Survival beats theory.

Every time.

🚀 Final Thoughts: Tradeoffs Build Winners

The best startup engineers don’t write perfect code.

They make imperfect decisionsat the right timefor the right reason.

Build for chaos.Ship the imperfect.Measure ruthlessly.Communicate boldly.

That’s how prototypes become real products.That’s how ideas turn into companies.

What’s the hardest tradeoff you’ve had to make?

PushEnv: A New, Encrypted Way to Manage .env Files (No SaaS, No Servers) 🔐

Shahnoor_Mujawar — Sat, 10 Jan 2026 06:06:43 +0000

Environment variables run everything.

But the way we manage them?Still messy. Still risky. Still outdated.

So I built PushEnv — a new way to handle secrets.

Here’s the story, in Q&A form.

Who am I and what is PushEnv?

I work across backend, DevOps, and AI infra.Every project I touched had the same problem:

Secrets were everywhere — and nowhere.

PushEnv is my attempt to fix that.

It’s a local-first, encrypted, Git-style workflow for .env files with:

Zero server trust
No SaaS
No lock-in

No dashboards.No logins.No plaintext.

What’s actually wrong with .env files?

On paper, .env files are simple.

In real life, they cause chaos:

Secrets get committed to Git
Keys are pasted into Slack
.env.example is outdated
Teammates have different versions
CI logs leak secrets
Docker images ship .env
No history
No rollback
No audit trail

Most teams rely on:

“Just don’t commit your .env.”

That’s not a strategy.That’s a hope.

Don’t existing tools already solve this?

They help — but they still require server trust.

Even “zero-knowledge” tools route secrets through:

APIs
Telemetry
Server infrastructure

That means:

Risk
Lock-in
Less transparency

What I wanted instead:

“Git for .env files — but encrypted and local-first.”

So I built it.

What makes PushEnv different?

PushEnv encrypts secrets before they leave your machine.

Only ciphertext is ever uploaded.

Key points

AES-256-GCM encryption
Passphrase never stored
Zero-knowledge encrypted secrets stored securely in PushEnv’s managed infrastructure
No central server
No accounts
Full version history
Open-source

The workflow

pushenv init, pushenv push, pushenv pull, pushenv diff, pushenv history, pushenv rollback

If you know Git + dotenv,you already know PushEnv.

Why did I build this?

Every project had the same issues:

Different .env everywhere
Secrets in Git history
“Send me the .env?”
No rollback
No diff
CI needing secrets without files
Docker images containing secrets

I wanted something that:

Works offline
Encrypts locally
Needs no login
Works in CI
Supports versioning
Is open-source

Nothing like that existed.

So I built PushEnv.

How does it work (quick version)?

1. Initialize

pushenv init

Choose environments + a passphrase.

Creates:
.pushenv/config.json (safe to commit) ~/.pushenv/keys.json (local keyring)

2. Push encrypted secrets

pushenv push -m "Initial setup"

Your .env is:

Encrypted locally
Uploaded as ciphertext
Versioned
Never stored in plaintext

3. Pull anywhere

pushenv pull

Secrets are decrypted locally and injected safely.

What about CI/CD and Docker?

That’s where PushEnv really shines.

Run apps without writing secrets to disk:
pushenv run "npm start"

Perfect for:

CI pipelines
Docker builds
Secure workflows
Ephemeral environments

Secrets vanish when the process exits.

What stacks does it support?

Anything that uses .env:

Node / Next / Nest
Python / Go
Docker / Kubernetes
GitHub Actions
AWS / Cloudflare / Vercel
S3 / R2 / MinIO

If your app uses env vars — PushEnv works.

Why does this approach matter?

Zero-trust servers

Storage only sees encrypted blobs.

No lock-in

Use your own infrastructure.

Easy to learn

No new mental model.

Full visibility

Diff, history, rollback — for secrets.

How can you try it?

npm install -g pushenv pushenv init pushenv push -m "First secrets"

More commands:
pushenv pull, pushenv diff, pushenv history, pushenv rollback --version N`

Where can you find it?

GitHub:https://github.com/shahnoorgit/pushEnv

NPM:https://npmjs.com/package/pushenv

MIT licensed.Open-source.Transparent.

Final thoughts

Secrets are too important to be:

Shared in Slack
Stored in plaintext
Locked behind SaaS
Lost without history

PushEnv gives developers:

A safer, simpler, and more transparent wayto manage environment variables.

Not an alternative.A new way.

🚀 Fixing One of the Most Annoying React Native Dev Problems: Localhost, Emulator Networking, and API URLs

Shahnoor_Mujawar — Tue, 06 Jan 2026 06:01:05 +0000

If you’ve built a React Native or Expo app that talks to a backend running on your local machine, you’ve probably hit this problem:

localhost works on iOS simulator
10.0.2.2 works on Android emulator
nothing works on a real device
teammates use staging or remote APIs instead

And suddenly you’re debugging:

network routing
emulator networking
.env file switching
platform-specific base URLs

…instead of debugging your actual app.

This post explains why this happens, what’s really going on under the hood, and how I built a small tool to make development API URLs “just work” — safely.

👉 Tool: rn-dev-url
npm: npm install rn-dev-url

🔍 Why localhost behaves differently in React Native

React Native runs in different environments depending on where the app executes — and each one treats localhost differently.

Understanding this helps a lot.

🟣 iOS Simulator — shares your computer network

The iOS simulator runs on your host machine, so:

http://127.0.0.1:

works fine — because both app + backend share the same network.

Everything feels intuitive here.

🟢 Android Emulator — runs in a virtualized network

The Android emulator runs inside a VM.

Inside that VM:

localhost refers to the emulator itself

not your computer

So Android exposes a special alias:

http://10.0.2.2:

That IP maps back to your host machine.

It makes sense once you know it —
but it’s very unintuitive if you don’t.

🟡 Physical Devices — different network entirely

A real device is:

on your Wi-Fi network
not running inside your machine
not in a simulator
So the only way to reach your machine is via:
http://:

Which may fail if:
router isolation is enabled
firewall blocks access
VPN / hotspot affects routing
So behavior changes again.
Meanwhile… teammates may be using staging APIs

So environments look like this:

Context URL
iOS Simulator 127.0.0.1
Android Emulator 10.0.2.2
Device LAN IP
Another Dev Staging API
CI / Preview Remote API

Same codebase
6 different networking realities

And every context break means…

👉 switching .env files
👉 restarting the packager
👉 changing axios base URLs
👉 explaining networking to teammates

Small problem — high frequency — major friction.

🛠️ So I built a small tool to solve this: rn-dev-url

Instead of juggling device-specific URLs, I wanted:

predictable behavior

production-safe guardrails

no magic or heuristics

explicit fallbacks

zero native dependencies

So I built:

👉 rn-dev-url

A tiny utility that automatically resolves the correct API URL in React Native / Expo development — while never exposing LAN IPs or doing smart detection in production.

⚡ Install
npm install rn-dev-url

yarn add rn-dev-url

🔧 How it works

In development, it safely tries:

1️⃣ Android Emulator → 10.0.2.2:
2️⃣ iOS Simulator → 127.0.0.1:
3️⃣ LAN Device → 192.168.x.x: (optional)

Optionally verifies connectivity via:

/health

If nothing is reachable:

👉 it falls back to your remote dev / staging API

🛡 In production — detection is disabled by design

No LAN scanning
No auto-resolution
No environment guessing

✔ prodUrl is required
✔ only production URL is used
✔ zero surprises

This was a deliberate design choice.

🧩 Usage Example
import { getDevApiUrl } from "rn-dev-url";

const apiConfig = await getDevApiUrl(3000, {
prodUrl: "https://api.example.com",
healthPath: "/health",
});

console.log(apiConfig.url);
console.log(apiConfig.source);

Possible outputs:

http://10.0.2.2:3000 android-emulator
http://127.0.0.1:3000 ios-simulator
http://192.168.1.42:3000 lan-device
https://api.example.com prod (fallback)

Then use it with axios / fetch:

const api = axios.create({
baseURL: apiConfig.url,
});

No platform checks
No .env juggling
No emulator-only bugs

🎯 Who this is useful for

This tool helps if you:

✔ run backend locally during development
✔ test on emulator + simulator + device
✔ work in a team with mixed setups
✔ switch between local + staging APIs
✔ care about predictable behavior

It’s especially useful for:

Expo apps

mobile API development

developer onboarding

debugging device-only bugs

🧠 Why I avoided “clever auto-magic”

A lot of tools fail because they:

❌ guess environment behavior
❌ silently switch modes
❌ expose LAN IPs in prod
❌ behave differently per device

Instead, this tool is:

boring
explicit
safety-first
predictable

I’d rather be conservative & trustworthy than “smart”.

🚀 Try it out
npm install rn-dev-url

GitHub repo:
https://github.com/shahnoorgit/rn-dev-url

Medium write-up:
https://medium.com/@shahnoormujawar/i-built-a-tiny-tool-to-fix-one-of-the-most-annoying-react-native-dev-problems-cf411ae3de39