Replace .env files
How to replace shared .env files
A local .env file is useful for a first prototype. It becomes a problem when the file is copied through chat, committed by accident, or silently out of date. RunEnv gives the team one project and environment workspace, then injects authorized values when the process starts.
How it works
Three steps for the supported path.
- 01
Create the project and environments
Sign in, create the application project, and keep development, staging, and production as separate environments instead of one shared file.
- 02
Link the repository
In the repo, run `runenv quickstart` or `runenv init --project <project-id> --env development`. `.runenv.json` stores linking metadata, not secret values.
- 03
Run without writing .env
Start the app with `runenv run -- npm start` (or your real command). Add values in the dashboard. Use a file workflow only when a tool cannot read process environment variables.
Why shared .env files fail
Plaintext files do not record who changed a key, which environment the value belongs to, or whether a teammate is still running yesterday’s copy. Anyone with the file sees every value.
- Secrets on disk are easier to commit, leak into backups, or pick up with malware.
- “It works on my machine” often means two .env files drifted.
- There is no approval step before a production value changes.
What replaces the file
Create a RunEnv project, keep development, staging, and production distinct, and start the app with `runenv run -- <your-command>`. For that path, values are injected into the child process environment and are not written to `.env`, `.env.local`, logs, or `.runenv.json`.
When you still need a file
Some tools require a file. RunEnv documents `runenv dotenv`, download, offline-cache, and `*_FILE` workflows separately. Those paths can write to disk. Use them as an explicit exception, then delete the file when the tool is done.