Definitions for .env file sharing terminology.

A hidden configuration file (the filename starts with a dot, making it hidden on Unix systems) that stores environment variables as key=value pairs. It is read by applications at startup to configure API keys, database URLs, secrets, and settings without hardcoding them into source code. The file should always be in .gitignore to prevent secrets from entering version control.

DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=sk_live_abc123
NODE_ENV=production

Dotenv refers to both the convention of storing environment variables in .env files and the npm package that loads them into process.env in Node.js applications. The dotenv package (npm install dotenv) has hundreds of millions of downloads and is the standard way to load .env files in JavaScript/TypeScript applications. The term is often used interchangeably with ".env file".

// Node.js usage
require("dotenv").config();
console.log(process.env.DATABASE_URL);

AES-256-GCM is a symmetric authenticated encryption algorithm. AES is the encryption cipher (Advanced Encryption Standard), 256 refers to the key size in bits (32 bytes), and GCM (Galois/Counter Mode) is the mode that provides both confidentiality and a 128-bit authentication tag. This means any tampering with the ciphertext is detectable and rejected. It is the encryption algorithm used by share-env.

// Node.js AES-256-GCM
const key = crypto.randomBytes(32); // 256 bits
const iv  = crypto.randomBytes(12); // 96 bits GCM
const cipher = crypto.createCipheriv("aes-256-gcm", key, iv);

A zero-knowledge relay server is a server that stores or transports data without being able to decrypt or understand it. In the context of share-env, the relay server stores only AES-256-GCM ciphertext. The decryption key never passes through the relay — it travels exclusively in the share code the user sends manually. Even if the relay server is fully compromised, an attacker obtains only unreadable ciphertext.

# What the relay receives (only):
{ ciphertext, iv, authTag }

# What it never receives:
{ key }  ← stays in share code

Burn-after-reading is a security pattern where a secret or piece of data is permanently and irrevocably deleted the moment it is accessed for the first time. In share-env, the encrypted .env payload is deleted from the relay server the instant it is pulled. If anyone attempts to retrieve the same share code a second time, they receive a 404 error. Nothing can be recovered after the first pull.

# Attempt to pull the same code twice:
$ npx share-env pull apple-brave-cloud#...
  Done! .env written.

$ npx share-env pull apple-brave-cloud#...
  Error: phrase not found (404)

In share-env, a share code is the one-time identifier returned after a push operation. It has the format phrase#hexKey, where the 3-word phrase (e.g. apple-brave-cloud) is the relay lookup identifier and the 64-character hex string after # is the AES-256-GCM decryption key. Both components together are required to retrieve and decrypt the payload. The key portion never passes through the relay server.

# Example share code format:
apple-brave-cloud#a3f9b2c1d4e5f6a7b8c9...
#                 ^--- 64-char hex AES key

An environment variable is a named value accessible to running processes via their environment. In application development, environment variables are used to configure applications without hardcoding values into source code. Common examples include DATABASE_URL, API_KEY, NODE_ENV, PORT, and JWT_SECRET. They are set differently per environment (local development, staging, production) and should never be committed to version control.

DATABASE_URL=postgres://user:pass@host:5432/db
API_KEY=sk_live_xxxxxxxxxxxxx
NODE_ENV=production
PORT=3000