Forem: Ivan Annovazzi

I Audited My Team's .env Practices. Here's What I Found.

Ivan Annovazzi — Thu, 26 Mar 2026 21:04:25 +0000

Last month I did something uncomfortable: I spent a Friday afternoon auditing how my team actually handles secrets. Not how we say we handle them. How we actually do it.

I checked Slack history, git logs, CI configs, and local machines. What I found wasn't a disaster — it was worse. It was normal. The kind of normal that every team thinks is fine until it isn't.

Here's exactly what I found, and what we did about it.

The audit

Team size: 5 developers, 3 services, 2 environments (staging + production).

I looked at five things:

1. Where do .env files live?

I asked everyone to run find ~ -name ".env" -not -path "*/node_modules/*" on their machines.

Combined results:

23 .env files across 5 laptops
7 of them contained production credentials
2 developers had .env files for projects they left months ago
1 file had a Stripe live key and a database URL on the same line — copy-paste artifact from Slack

The problem isn't that .env files exist. It's that they accumulate. Nobody cleans them up. Nobody knows how many copies are out there.

2. How do new devs get credentials?

I searched our Slack for "env", "password", "key", "token", and "secret".

14 messages containing actual credentials in the last 6 months
3 of those were in a public channel (we caught that quickly, at least)
The onboarding doc said "ask someone for the .env" — no specifics about who, which values, or which environment

The worst part: Slack retains message history. Those credentials are sitting in Slack's servers forever unless someone manually deletes each one.

3. Are secrets in git history?

# Quick check for common patterns
git log --all -p | grep -E "(API_KEY|SECRET|PASSWORD|TOKEN)=" | head -20

Two hits. Both were "temporary" commits from months ago that were reverted — but the values are still in the history. git revert doesn't erase data. Anyone who clones the repo gets those secrets.

4. How does CI/CD get secrets?

Our GitHub Actions workflows used repository secrets. Fine in principle, but:

4 people had admin access to the repo (and could read all secrets)
No rotation schedule — some secrets hadn't been updated in over a year
No audit log of who accessed what

5. What happens when someone leaves?

We'd had one departure in the past year. Checked the offboarding:

GitHub access revoked ✓
AWS IAM removed ✓
Secrets rotated ✗

Every API key, database password, and service token that developer had access to was still active. For four months.

The scorecard

Practice	Status
Secrets encrypted at rest	✗ (plaintext .env files)
Secrets shared securely	✗ (Slack DMs)
Secrets rotated on departure	✗
Secrets rotated on schedule	✗
Git history clean	✗
Least-privilege access	✗
Audit trail	✗

Zero out of seven. And we're not a careless team. We write tests. We do code review. We just never formalized secrets management because it always felt like a "later" problem.

What we changed

We didn't do everything at once. Here's the order that worked for us:

Week 1: Stop the bleeding

Rotated every secret that the departed developer had access to. This took half a day and was painful — but it's the highest-impact thing you can do.

Deleted secrets from Slack. Searched, found them, deleted each message. Then pinned a message in #engineering: "Never paste credentials here. Not even temporarily."

Scrubbed git history using BFG Repo-Cleaner:

bfg --replace-text passwords.txt repo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive

Then force-pushed and had everyone re-clone. Annoying but necessary.

Week 2: Centralize secrets

We evaluated three options:

HashiCorp Vault — powerful, but needs dedicated ops. We're 5 people.
Doppler — solid, but more surface area than we needed.
KeyEnv — CLI-first, minimal setup, fit our workflow.

We went with KeyEnv because the migration was zero-friction:

# Import existing .env
keyenv push

# From now on, every developer does:
keyenv pull

# Or skip the file entirely:
keyenv run -- npm start

No code changes. Apps still read process.env. The difference is that secrets come from an encrypted store instead of a file someone pasted in Slack.

Week 3: Lock down access

Set up per-environment permissions. Junior devs get development only. Production secrets are admin-restricted.
Created service tokens for CI/CD — scoped, rotatable, auditable.
Established a quarterly rotation schedule (calendar reminder, nothing fancy).

Week 4: Wrote it down

Added a SECRETS.md to each repo:

## Secrets Management

This project uses KeyEnv for secrets management.

### Setup
1. Get invited to the team: ask in #engineering
2. `keyenv pull` to get development secrets
3. `keyenv run -- npm start` to run with injected secrets

### Rules
- Never commit secrets to git
- Never share secrets via Slack, email, or docs
- Rotate secrets when a team member leaves
- Production secrets require admin access

Run your own audit

You can do this in an afternoon. Here's the checklist:

[ ] Search Slack for credentials (password, key, token, secret, .env)
[ ] Count .env files across developer machines
[ ] Check git history for leaked values
[ ] Review who has access to CI/CD secrets
[ ] Verify secrets were rotated after last departure
[ ] Check if any service accounts use shared credentials

You'll probably find what I found: not a catastrophe, but a pile of small risks that compound over time.

The fix doesn't require enterprise tooling. It requires deciding that secrets management matters, then picking any system that's better than Slack + .env files.

Have you ever audited your team's secret practices? I'm curious what others have found — especially the "normal" stuff that everyone does but nobody talks about.

Moveet: Building a City-Agnostic Fleet Simulator with Real Road Networks and Live Traffic

Ivan Annovazzi — Thu, 19 Mar 2026 11:06:15 +0000

Moveet is an open-source, real-time vehicle fleet simulator built in TypeScript. It runs vehicles on actual road networks with A* pathfinding, realistic traffic modeling, and a custom D3-based map renderer — no Leaflet, no Mapbox, no tile provider.

The latest release makes the simulator fully city-agnostic. Point it at any city, and it builds a routable graph from OpenStreetMap data, complete with congestion modeling, geofencing, and a live traffic overlay. Here is what went into it.

From OSM Data to a Routable Graph

A CLI pipeline (apps/network) handles the full OpenStreetMap ingestion:

npm run dev -- prepare nairobi

This downloads a country PBF from Geofabrik, clips a bounding box with osmium (via Docker), filters to drivable road classes, exports GeoJSON, and validates the topology. Cached after first run. A regions.json manifest covers major cities globally — switching cities is a one-argument change.

The builder prunes disconnected components, parses OSM tags like lane counts, surface quality, roundabouts, access restrictions, and traffic signals, and handles edge cases like reversed one-ways and near-duplicate nodes.

Traffic Realism

The A* engine applies a BPR (Bureau of Public Roads) congestion function when computing route costs. Road capacity is derived from OSM lane data. As vehicles accumulate on a segment, the routing cost grows and traffic naturally shifts to alternative corridors — the same principle used in professional traffic assignment models.

Additional realism layers include surface quality speed factors, traffic signal intersection delays, and an incident-aware route cache keyed by active incident state.

A simulation clock drives time-varying demand — rush hour amplification, night reduction — and the server broadcasts per-edge congestion snapshots at a regular interval. The UI renders them with a Google Maps-style color ramp (green through red), with only roads carrying actual traffic colored.

Routing Quality

The A* router now handles OSM turn restrictions, enforces forward-only roundabout traversal with speed reduction, filters out private and restricted-access roads, and computes an admissible heuristic from the network's actual speed range rather than a hardcoded constant.

Geofencing

Draw polygons on the map, name them, assign types and colors. The server runs ray-casting checks every tick and broadcasts enter/exit events over WebSocket. Full REST CRUD, an alerts panel, and per-zone toggle are included.

Vehicle Types and Trails

Car, truck, motorcycle, ambulance, and bus — each with distinct speed profiles, acceleration curves, road restrictions, and special behaviors. Fleet composition is configurable at start time.

Each vehicle also leaves a fading breadcrumb trail on the map, stored in a circular buffer and rendered as an opacity gradient. Trail length is adjustable.

WebSocket Subscribe Filters

Clients can filter their WebSocket feed by fleet, vehicle type, or geographic bounding box:

{ "type": "subscribe", "filter": { "fleetId": "fleet-1", "vehicleType": "truck" } }

Backwards-compatible — clients without a filter receive everything.

UI Overhaul

All interactive components were migrated to React Aria for proper accessibility. The visual layer received a glassmorphism theme with tiered depth, a custom fuzzy search with match highlighting, and tighter panel proportions.

Under the hood: a fleet analytics dashboard with sparkline KPIs, structured logging with correlation IDs, a health endpoint, and CI-enforced test coverage across all workspaces.

Try It

git clone https://github.com/ivannovazzi/moveet.git
cd moveet && npm install && npm run dev

Dashboard at localhost:5012. MIT licensed. GitHub repo.

Lots of new features coming soon. Performance boosts, traffic simulations, vehicle types and more.

Ivan Annovazzi — Mon, 16 Mar 2026 10:44:25 +0000

Moveet: incidents, recording & replay, fleet management, dispatch flows, and 500+ tests

Ivan Annovazzi ・ Mar 16

#showdev #opensource #typescript #webdev

Moveet: incidents, recording & replay, fleet management, dispatch flows, and 500+ tests

Ivan Annovazzi — Mon, 16 Mar 2026 10:38:17 +0000

A few months ago I shipped the first version of Moveet — an open-source real-time vehicle fleet simulator that runs vehicles on actual road networks using A* pathfinding, streams positions over WebSocket, and renders everything in a custom D3 SVG map without touching Leaflet or Mapbox.

Since then a lot has landed. Here's what's new.

What shipped

🚦 Fleet management

Vehicles can now be grouped into named, colour-coded fleets. You create a fleet, assign vehicles to it, and the UI colours routes and markers per fleet. Useful when you want to simulate multiple operators or companies sharing the same road network.

REST API:

POST   /fleets
GET    /fleets
DELETE /fleets/:id
POST   /fleets/:id/assign
POST   /fleets/:id/unassign

Fleet events are broadcast over WebSocket in real time (fleet:created, fleet:deleted, fleet:assigned).

⚠️ Incidents and dynamic rerouting

You can now drop a road incident anywhere on the network. Every vehicle currently routing through the affected segment gets rerouted live — A* reruns from their current position, routing around the blocked edge.

POST   /incidents          # create incident, triggers rerouting
GET    /incidents          # list active
DELETE /incidents/:id      # clear it, vehicles return to normal paths
POST   /incidents/random   # random incident for testing

Incident markers appear on the map. The vehicle:rerouted WebSocket event fires for each affected vehicle.

🎬 Session recording and replay

Every simulation session can be recorded to a timestamped NDJSON file. The format is a header line followed by one event per line — direction assignments, vehicle snapshots, incidents, everything.

POST   /recording/start
POST   /recording/stop
GET    /recordings

Replay loads any recording file and plays it back with full control:

POST   /replay/start    { "file": "path/to/recording.ndjson" }
POST   /replay/pause
POST   /replay/resume
POST   /replay/stop
POST   /replay/seek     { "timestamp": 12000 }
POST   /replay/speed    { "speed": 2 }
GET    /replay/status

Playback supports 1×, 2×, and 4× speed. The UI has an interpolated progress bar that advances smoothly between server ticks, so it doesn't jump every 500 ms.

🖥 UI redesign: icon rail + panel sidebar

The controls were previously a floating overlay. They're now an icon rail on the left edge — a vertical strip of icon buttons that each toggle a panel.

Panels:

Icon	Panel
��	Vehicles — list, filter, select
🗂	Fleets — create, assign, colour
⚠️	Incidents — active list with badge count
⏺	Recordings — start/stop/browse/replay
👁	Visibility — toggle map layers
⚡	Speed — simulation speed controls
⚙️	Adapter — hot-swap source/sink plugins

The bottom dock holds live simulation controls (play/stop/reset/record) and collapses to a replay transport bar during playback.

All panel components are built from a shared set of primitives (PanelShell, PanelHeader, PanelSection) and a unified theme token set, so every panel looks consistent without per-component ad-hoc styling.

✅ Test coverage: from 410 to 502 tests

The simulator test suite grew significantly. New files added:

File	What it covers
`rateLimiter.test.ts`	Window enforcement, 429 responses, per-IP tracking, cleanup interval
`helpers.test.ts`	`calculateBearing`, `interpolatePosition`, `calculateDistance`, `nonCircularRouteEdges`, `estimateRouteDuration`
`serializer.test.ts`	`serializeVehicle` with and without fleet assignment
`config.test.ts`	`verifyConfig` — missing file, port range, speed ordering, all numeric constraints
`SimulationController.test.ts`	Full lifecycle: `start`, `stop`, `getStatus`, `setOptions`, `getVehicles`, `getInterval`, all replay methods

The pattern for testing SimulationController is worth noting: construction stubs VehicleManager.prototype.setRandomDestination to prevent A* calls on the tiny test-network fixture, then restores it. Replay tests write a minimal NDJSON file to a temp dir before each test. Everything cleans up in afterEach.

📡 WebSocket: 100 ms batching + backpressure

Vehicle position updates are now batched at 100 ms before broadcast. If a client's write buffer is backed up, the broadcaster skips it rather than growing an unbounded queue. This makes the simulator usable with 50–100 vehicles without the connection degrading.

All event types the simulator broadcasts:

vehicles          – batched position array (100ms window)
status            – simulation state (running / ready / interval)
options           – current StartOptions
heatzones         – HeatZoneFeature[]
direction         – active dispatch assignment
waypoint:reached  – vehicle reached a waypoint
route:completed   – vehicle completed its full route
reset             – simulation was reset
fleet:created / fleet:deleted / fleet:assigned
incident:created / incident:cleared
vehicle:rerouted  – live A* reroute triggered

🔧 CI improvements

The GitHub Actions workflow previously ran npm ci three times in parallel — once per job. It now has a dedicated setup job that installs once and caches node_modules keyed on package-lock.json. Lint, test, and build jobs restore from cache. The build job also caches .turbo/ with a per-commit key and branch-level restore keys.

Architecture diagram (updated)

┌──────────────────────────────────────┐
│  apps/ui                             │
│  React 19 · D3 7 · Vite · TS 5.8    │
│  Mercator SVG map, 1×–15× zoom       │
│  Icon rail · Panel sidebar · Dock    │
└──────────────┬───────────────────────┘
               │ REST + WebSocket
               ▼
┌──────────────────────────────────────┐
│  apps/simulator                      │
│  Express 4 · ws 8 · Turf.js 7       │
│  GeoJSON graph · A* · LRU cache      │
│  WS broadcaster · 100ms batching     │
└──────────────┬───────────────────────┘
               │ GET /vehicles · POST /sync
               ▼
┌──────────────────────────────────────┐
│  apps/adapter (optional)             │
│  Source plugins: static / graphql /  │
│  rest / mysql / postgres             │
│  Sink plugins: console / graphql /   │
│  rest / redpanda / redis / webhook   │
└──────────────────────────────────────┘

Try it

curl -O https://raw.githubusercontent.com/ivannovazzi/moveet/main/docker-compose.ghcr.yml
docker compose -f docker-compose.ghcr.yml up

Open http://localhost:5012. No config, no API keys.

Repo: github.com/ivannovazzi/moveet

Happy to answer questions about the A* implementation, the D3 renderer, or the recording format in the comments.

Your .env Files Are a Security Incident Waiting to Happen

Ivan Annovazzi — Wed, 11 Mar 2026 20:38:12 +0000

You've done it. I've done it. We've all done it.

Pasted a .env file into Slack. Committed DATABASE_URL to a repo "just temporarily." Spent 45 minutes debugging prod because someone was running against staging credentials and nobody realized it. Onboarded a new dev by saying "ask Sarah for the .env file" — and Sarah sends it over Gmail.

This is how secrets get leaked. Not through sophisticated attacks. Through completely normal, everyday developer workflows.

KeyEnv is our answer to this. And today, we're officially launching with a batch of updates that make it genuinely ready for teams.

What KeyEnv Actually Does

KeyEnv replaces your scattered .env files with a secure, centralized workflow that fits into how you already work — without changing how your apps consume environment variables.

Secrets are encrypted at rest with AES-256-GCM, scoped per project and per environment (dev, staging, production), and access is managed per team member. There's a full audit trail. You can rotate secrets, compare environments, and view version history — all from the CLI or the web dashboard.

The key idea: your app never needs a .env file on disk. Secrets are injected at runtime.

# Install the CLI
curl -fsSL https://keyenv.dev/install.sh | sh

# Authenticate with a service token from the dashboard
keyenv login

# Run your app — secrets are injected directly into the process
keyenv run -- npm start
keyenv run -- docker-compose up
keyenv run -- python manage.py runserver

That's it. No plaintext file sitting on disk. No risk of accidentally committing it. No "wait, which .env is this?"

If you're working with a legacy app that reads from a .env file directly, keyenv pull still works — but keyenv run is the better path forward.

The Full Workflow in 30 Seconds

# See what's different between local and remote before pushing
keyenv diff

# Push your local secrets up
keyenv push

# Pull the latest from the server
keyenv pull

# Manage secrets directly
keyenv set API_KEY=abc123
keyenv get API_KEY
keyenv delete OLD_SECRET

# Check the version history of a secret
keyenv history API_KEY

# Switch between projects
keyenv switch my-other-project

The CLI is written in Rust — fast, single binary, no runtime dependencies. Releases are now signed with an Ed25519 keypair so you can verify what you're installing.

What Just Shipped

We've been heads-down building. Here's what's live now:

Audit log viewer — full history of who accessed or changed what, when. Compliance teams will ask for this eventually. Now you have it.
Environment comparison view — see the diff between dev, staging, and production side by side. Catch the "why is this broken in prod but not locally?" problem before it happens.
Service token management — generate scoped tokens for CI/CD pipelines and automated workflows, managed from the dashboard.
Bulk import fix — .env files with empty values now import correctly. Sounds minor. Was definitely annoying.
Team plan at $4/user/month — straightforward pricing. No tiers designed to confuse you into the wrong one.

How It Compares

There are other tools in this space. Here's the honest version:

Tool	Setup time	Team sync	No .env on disk	Hosted SaaS
KeyEnv	Minutes	Yes	Yes (keyenv run)	Yes
HashiCorp Vault	Hours to days	Yes	Yes	No (self-host)
Infisical	15-30 min	Yes	Yes	Yes (or self-host)
1Password Secrets	20-40 min	Yes	Partial	Yes
dotenv-vault	Minutes	Limited	No	Yes

Vault is powerful, but if you're a 3-person startup, you don't want to maintain Vault. Infisical is solid but the onboarding has more surface area than most teams need. dotenv-vault encrypts your .env file — which is better than nothing, but it's still a file, and team sync is clunky. KeyEnv is designed to get you from "I have a problem" to "my team is using this" in under 10 minutes.

CI/CD Works Too

Service tokens mean you can pull secrets in any pipeline without storing credentials in your CI provider's environment variables UI (which is itself a kind of scattered .env problem).

# In your GitHub Actions workflow
- name: Run tests
  env:
    KEYENV_TOKEN: ${{ secrets.KEYENV_SERVICE_TOKEN }}
  run: keyenv run -- npm test

Secrets stay in KeyEnv. Your CI environment only holds one bootstrap token with scoped access.

Try It

KeyEnv is live at keyenv.dev. The CLI install is one line, the free tier covers solo projects, and the team plan is $4/user/month.

If you've got feedback — things that don't work the way you expect, features you'd want before switching from your current setup, anything — open an issue at github.com/keyenv/keyenv or reach out directly. We're actively building this and want to hear what's actually blocking people.

The .env file had a good run. There's a better way now.

Simulate a Moving Fleet on Real Roads Before You Have a Single Real Vehicle

Ivan Annovazzi — Wed, 11 Mar 2026 20:33:18 +0000

You're building a fleet management dashboard. You need GPS positions updating in real time, vehicles following actual road networks, realistic speed changes through intersections, and enough concurrent units to stress-test your WebSocket layer. The problem: you don't have a fleet.

Mocking this properly is harder than it sounds. Static fixtures go stale the moment your UI needs live movement. Random coordinate walks ignore roads entirely. Hand-rolling a simulator burns days you don't have.

Moveet solves this. It's an open-source, real-time vehicle fleet simulator that runs on actual road networks and streams GPS positions, routes, and traffic data over WebSockets.

What It Actually Does

Moveet ingests a GeoJSON road graph (OpenStreetMap-derived or your own), builds a bidirectional weighted graph from it, and runs a fleet of simulated vehicles across it continuously.

Each vehicle:

Finds routes using A* pathfinding with a haversine heuristic
Applies a realistic motion model - acceleration on straights, deceleration into turns
Emits position updates over WebSocket as it moves

On top of that, Moveet derives heat zones from high-connectivity intersections in the road graph, giving you traffic-density regions that behave like real congestion patterns.

There's also a built-in operator UI - a React + D3 renderer that draws routes directly onto SVG without touching Leaflet, Mapbox, or any tile provider. No API keys, no external dependencies.

Architecture in Three Layers

apps/ui          (React + D3 route renderer)
     |  REST + WebSocket
     v
apps/simulator   (simulation engine - road graph, A*, motion model)
     |  GET /vehicles, POST /sync
     v
apps/adapter     (optional bridge to external fleet APIs)
     |  GraphQL + Kafka / Redpanda
     v
Your app or local dev stack

The simulator is the core. The adapter is optional - use it when you need to sync simulated vehicle state into an external fleet management API.

Up and Running in One Command

curl -O https://raw.githubusercontent.com/ivannovazzi/moveet/main/docker-compose.ghcr.yml
docker compose -f docker-compose.ghcr.yml up

Open http://localhost:5012. You'll have a live fleet moving across a road network, streaming positions in real time.

No local Node setup, no dependency resolution, no config files to wrangle before you see something move.

Plug In Your Own Data Sources and Sinks

Moveet's plugin architecture is where it gets genuinely flexible for CI and staging environments.

Sources control where vehicle and road data come from:

Plugin	Use case
Static	Local GeoJSON files, great for deterministic CI runs
GraphQL	Pull live road data from your own API
REST	Any HTTP endpoint that returns road/vehicle data
MySQL / PostgreSQL	Seed directly from your existing database

Sinks control where simulated positions go:

Plugin	Use case
Console	Quick local debugging
REST / GraphQL	Push to your backend during integration tests
Kafka	Stream into your existing event pipeline
Redis	Pub/sub for downstream consumers
Webhook	Fire-and-forget to any HTTP listener

This means you can wire Moveet directly into your staging stack and have your actual application code consume simulated vehicle events - same path as production, simulated data.

The Stack

TypeScript throughout (ES2022), Node.js + Express + ws on the server, React 19 + D3 v7 + Vite on the client, Turf.js for geospatial math, Vitest for testing, Turborepo for the monorepo build. Docker Compose for deployment.

When to Use It

Local development - realistic moving data without a staging environment dependency
Integration testing - deterministic scenarios via static source plugin, repeatable in CI
Load testing - scale vehicle count to stress-test your WebSocket handling
Demo environments - show a live-looking dashboard without exposing real fleet data

Get Involved

The project is on GitHub at github.com/ivannovazzi/moveet. It's early-stage and actively developed.

If you're building anything in the fleet space and have spent time wrestling with test data, take it for a spin. Issues, PRs, and feedback welcome.

How we replaced .env files across 5 microservices without touching the app code

Ivan Annovazzi — Tue, 24 Feb 2026 16:39:11 +0000

The .env file tax is real. Every time we onboard a new developer, someone has to share credentials over Slack. Every time we add a service, there's another .env.example to maintain. By our fifth microservice, we had a mess.

This is the story of how we moved all five services to a central secrets manager — without touching a single line of app code.

The Problem We Had

Our stack looked something like this:

api-gateway — Node.js, reads 12 env vars
auth-service — Node.js, reads 8 env vars
billing-service — Node.js, reads 6 env vars
notification-service — Python, reads 5 env vars
analytics-worker — Go, reads 4 env vars

Each service had its own .env.example. New developer? "Hey, ask someone for the values." Production values? "Check the secret Notion page." Rotation? "Good luck, touch every service manually."

The breaking point came when we rotated a database password and missed one service. Three hours of debugging a production incident traced back to a stale .env file.

Why Not Just Vault?

HashiCorp Vault is the "right" answer at scale. But setting up Vault for a 5-person team means:

Running and maintaining a Vault cluster
Setting up auth methods, policies, lease management
Building tooling to inject secrets at runtime

We wanted something that felt more like dotenv but with team access controls, encryption, and auditability.

The Approach: Treat Secrets as Ephemeral Artifacts

The key mental shift is this: a .env file is not configuration, it's a generated artifact.

Instead of storing .env files:

Secrets live in an encrypted store (we used keyenv.dev)
Each developer runs keyenv pull to generate a fresh .env for their environment
CI/CD pipelines do the same in their build step
The generated .env is ephemeral — never committed, never shared

What We Changed (Per Service)

Here's the thing: we changed nothing about how the services consume secrets.

All five services already read from environment variables via process.env, os.environ, or os.Getenv. They continued to do that. We just changed how the .env got there.

Before:

# Copy from teammate over Slack
cp .env.example .env
# Edit manually

After:

keyenv pull --env development
# .env generated from encrypted store

For production deploys, we added one line to our CI pipeline:

keyenv pull --env production

That's it. No SDK integration. No sidecar containers. No code changes.

Per-Environment Scoping

The feature that made this work cleanly is environment inheritance. We defined secrets at three levels:

Shared — keys used across all environments (service names, feature flags)
Per-environment — DATABASE_URL, STRIPE_SECRET_KEY differ per env
Per-service — only relevant to one service

When you run keyenv pull --env staging, you get the merged result. Each developer gets the right values for their environment without needing to know the production secrets.

Rotation in One Place

When we had to rotate our Stripe key (a quarterly security practice), the old workflow was:

Generate new key in Stripe dashboard
Update 3 services that use it
Hope nothing breaks in production
Realize you forgot the analytics worker
Fix the analytics worker

The new workflow:

Generate new key in Stripe dashboard
keyenv set STRIPE_SECRET_KEY <new_value> --env production
Deploy (each service pulls fresh on next start)

Done in 90 seconds. Full audit trail showing who changed what and when.

What We Gained

Zero secrets in Slack — new developers get access via team invite, not copy-paste
No stale .env files — pull always reflects current state
Rotation without touching services — update the store, redeploy
Audit trail for compliance — who accessed what and when

What This Doesn't Solve

To be clear about the limits:

Runtime secret injection — if you need secrets to change mid-run without restarting, you'll want something with dynamic leases (Vault)
Infrastructure secrets — Terraform state, cloud provider credentials are better handled by the cloud provider's native tools
Very large teams — at 50+ developers, the enterprise features of Doppler or Infisical start to matter

For a 5-person team with 5 microservices in a multi-environment setup, this approach eliminated our entire class of "wrong credentials" incidents.

Takeaway

The pattern that eliminated our credential chaos:

Secrets belong in an encrypted store, not in files
.env files are generated artifacts, not source-controlled config
Every service gets its secrets the same way: pull at startup
Apps don't need to know any of this — they still read env vars

If you're still copying .env files around, try treating them as generated artifacts for a week. The operational simplification is immediate.