Introduction to RunEnv

RunEnv centralizes environment configuration and supports scoped runtime delivery, version history, and team access controls.

The Problem with .env Files

For years, developers have relied on .env files to store configuration and secrets locally. However, this approach introduces several critical issues:

1. Security Risks: Secrets stored in plain text on disk are easily compromised by malware, accidental commits, or unauthorized access.
2. Synchronization Issues: "It works on my machine" often stems from developers having outdated or mismatched .env files. Sharing .env files over Slack or email is a common, insecure anti-pattern.
3. No Audit Trail: You cannot easily track who changed a database URL or when an API key was rotated.
4. Lack of Access Control: Anyone with access to the .env file sees all the secrets. There is no granular control based on roles.

The RunEnv Solution: Zero-Disk Architecture

For no-file delivery, runenv run retrieves the selected environment values and injects them into the child process environment without creating a .env file. Download, offline-cache, and secret-file workflows intentionally use different storage boundaries.

How It Works

Instead of running:

node server.js

You run:

runenv run -- node server.js

Behind the scenes:

1. The RunEnv CLI authenticates your machine.
2. It fetches the encrypted secrets for your specific environment (e.g., development).
3. It decrypts the secrets in memory and spawns node server.js with those secrets securely injected as environment variables.

Beyond the Basics

RunEnv goes far beyond simple .env replacement. As your team grows, you can leverage its enterprise-tier features:

• Change Requests: Require approvals before changing production secrets.
• Dynamic Secrets: Generate short-lived database credentials on the fly.
• Transit Engine: Use RunEnv to encrypt your application data (like PII) with our Encryption-as-a-Service API.