Your keys are sitting in plaintext on disk

Almost every project keeps its credentials in a .env file, and almost every .env file is unencrypted text sitting in a project directory. That is not a mistake anyone made — it is the documented convention, and the tooling assumes it.

The problem is not the file. The problem is everything else on the machine that quietly reads files, and the fact that a plaintext secret has no idea it is a secret.

How it actually bites

1. It is in your backups, forever

   Time Machine, File History and every cloud sync client copy the project directory as-is. A key you rotated last year is still readable in a snapshot from the week before you rotated it, and snapshot retention is measured in months.

2. Anything you npm install can read it

   A postinstall script runs with your user account and your filesystem permissions. It does not need an exploit to read ~/projects/*/.env — it just needs to be installed, which is the entire point of a package manager.

3. It follows the folder

   Copy the project to an external drive, hand a laptop to a colleague for an afternoon, or restore an old directory to check something, and the keys come along. Nobody thinks of a directory copy as a credential transfer.

4. Crash reporters and log shippers scoop it up

   Plenty of tools capture environment variables alongside a stack trace to help you debug. That is useful behaviour, and it is also how a production key ends up in a third-party error dashboard that half the team can read.

What we do about it

1. Encrypted at rest, on your device

   Keys are encrypted with AES-256-GCM using a key derived from your master password via PBKDF2-SHA-256 at 600,000 iterations. The stored form is ciphertext. A backup of it, or a copy of it, is ciphertext too.

2. The password never leaves the machine

   Derivation happens in the browser through the Web Crypto API, and the derived key is marked non-extractable, so not even our own code can read it back out — a test asserts that flag on every derivation. Sharing a project uses a separate keypair, whose private half is encrypted with your master password before it is stored; it is never written or sent in the clear.

3. A .env file only when you ask for one

   You generate the file at the moment you need it, for the project you need it for. It is an output, not the place your keys live, so deleting it costs you nothing.

4. Six export targets, correctly escaped

   Beyond .env, the extension writes shell exports, Docker env files, GitHub Actions secret commands, gcloud commands and Kubernetes manifests. Each has its own quoting rules, and getting them wrong silently corrupts any value containing a quote, a newline or a leading space.

Questions

1. Is it really a problem to keep API keys in a .env file?

   A .env file is plaintext on disk, readable by every process running as you — including your editor extensions, your package manager's post-install scripts, and anything that got in. It is fine as a way to pass configuration to a process, and it is not storage. The distinction matters because most leaks are not attacks, they are copies: a backup, a screen share, a file synced to cloud storage that was never meant to leave the machine.

2. Does .gitignore make a .env file safe?

   It stops one specific accident. It does nothing about the file being readable by other software on the machine, about it ending up in a Docker build context, about it being copied to a colleague over chat, or about it already being in your git history from before the rule existed.

3. What does APIKeyConnect do differently?

   Keys are encrypted with AES-256-GCM under a key derived from your master password with PBKDF2-SHA-256 at 600,000 iterations. What sits at rest is ciphertext, so a copy of it is a copy of ciphertext. You still get a .env when you need one — generated on demand, into the project that asked for it, rather than living there permanently.

4. Can I still use .env files with my tooling?

   Yes, and you will. The point is not to abolish the format, it is that the file stops being the only copy. Generate it when you need it, delete it when you do not, and keep the durable copy encrypted.