Core Concepts

lazyenv is intentionally simple:

• .env.example is the source of truth for which keys exist.
• Your store is the source of truth for secret values.
• .lazyenv/config.json describes how this repo maps to a store, project, environments, and monorepo folders.

.env.example is the contract

lazyenv discovers keys by scanning .env.example files.

• Values in .env.example are placeholders.
• If a key exists in .env.example, lazyenv considers it part of your app’s required configuration.

Stores

You pick an explicit store and then use the same workflow everywhere:

lazyenv init --store <infisical|doppler|bitwarden|onepassword>
lazyenv sync
lazyenv pull
lazyenv run pnpm dev

The main store‑specific behavior is folder mapping (native paths vs prefixes). See Store Architecture.

Workspace folders (monorepos)

Each .env.example file becomes a workspace folder. That folder:

• has a local path (where the file lives)
• maps to a store namespace via secretPath
• avoids collisions (two packages can both have DATABASE_URL)

Conceptually:

Local path	Store namespace (secretPath)
.	/
apps/web	/apps/web
apps/api	/apps/api

Most CLI commands resolve the active folder from your current working directory.

Environments

Commands operate on an environment (usually one at a time):

lazyenv sync --env dev
lazyenv pull --env prod

For automation, combine --yes (no prompts) with explicit flags. See CI/CD Integration.

Provisioners and rules

Provisioners generate values. Rules decide when they apply.

• provisioners: named generators (browser flows, random generators, programs).
• provisionerRules: match patterns that select a provisioner and define behavior like onMissing, allowNonInteractive, and rotation.

In the CLI wizard, you can select an existing provisioner for a key (or create a new one).

See Provisioners for the available kinds and examples.

Next

• Commands: CLI Commands
• Config shape: .lazyenv/config.json