.env file vs a secrets manager
Your .env file is a per-machine copy; a secrets manager is one store every machine reads. Comparison, when a file suffices, and the move with penv push.
Your .env file is a copy on each laptop, runner and server, with nothing connecting the copies. A
secrets manager holds one set of values that every machine of yours reads at start.
Comparison
| Concern | .env file | Penv Cloud |
|---|---|---|
| Who holds a value | Everyone ever sent it | The listed members and machines, now |
| Who read it, when | Unknown | Audit log, one entry per read |
| Change a value | Send a new file to everyone | Change it once |
| Someone leaves | Rotate every key they saw | Remove them; access stops |
| CI access | Long-lived token in CI settings | Machine identity, no stored key |
| At rest | Plain text on disk, unless you opt in to penv encrypt | Encrypted under a per-workspace key |
When a file suffices
All of these hold:
- You alone, or a team that rotates keys in person.
- No CI, or CI with no credentials.
- No end-user data behind the keys.
Application code
# file
node server.js
# cloud
penv run -- node server.jspenv run puts values in the child process environment and masks them in its
output. Your app reads process.env.STRIPE_SECRET_KEY as before: no SDK, no code change. The same
.env.schema validates values from either source. See local and cloud modes.
Move to Penv Cloud
penv pushpenv push uploads your values and deletes the local file once we confirm the
write. penv pull writes a fresh file at any time.
We can decrypt your values in order to serve them to your machines, as every hosted secrets manager can; this is not zero-knowledge. Encryption in the cloud states what we can and cannot do.