Local Secrets
The LPM CLI local vault stores project environment variables without requiring an LPM.dev Registry account or network connection.
lpm env set DATABASE_URL=postgres://localhost/app
lpm env get DATABASE_URL
lpm env list
Store and Read Values
set accepts one or more KEY=VALUE pairs:
lpm env set API_KEY=sk-local
lpm env set "GREETING=hello world" PORT=3000
lpm env set --env=staging API_KEY=sk-staging
Setting an existing key replaces its value.
Reads are masked by default:
lpm env get API_KEY
lpm env list
Use --reveal only when plaintext output is intentional:
lpm env get API_KEY --reveal
lpm env list --reveal
get --reveal prints the raw value. list --reveal prints every key and value in the selected environment.
Delete one or more values with:
lpm env delete API_KEY
lpm env delete API_KEY DATABASE_URL
Import and Export Dotenv Files
lpm env import .env
lpm env import .env.production --env=production
lpm env import .env --overwrite
An import skips keys that already exist unless --overwrite is supplied. LPM CLI adds the imported file to the project .gitignore.
Export writes plaintext:
lpm env export .env.backup
lpm env export .env.staging --env=staging
LPM CLI writes exports atomically, uses owner-only 0600 permissions on Unix, and adds the output path to .gitignore. Treat the resulting file as a secret even though it is ignored by Git.
Dotenv parsing supports assignments, comments, quoted values, and export KEY=VALUE. It does not expand $OTHER_VARIABLE references.
Print a Resolved Environment
lpm env print combines dotenv files, vault values, environment inheritance, and schema defaults. Its default format is dotenv:
lpm env print
lpm env print --env=staging
lpm env print --format=json
To export values into the current shell, request shell syntax explicitly:
eval "$(lpm env print --format=shell)"
Printing or evaluating an environment reveals its values. Prefer lpm run or lpm dev, which inject the resolved environment directly into the child process.
Validate an Environment Schema
Define the schema under lpm.json > envSchema > vars:
{
"envSchema": {
"vars": {
"DATABASE_URL": {
"required": true,
"format": "url",
"secret": true
},
"PORT": {
"required": false,
"format": "port",
"default": "3000"
}
}
}
}
lpm env check
lpm env example
lpm env check validates every discovered environment against the schema. It reports missing required values, invalid formats, pattern failures, and other rule violations. It does not accept an environment selector.
lpm env example generates .env.example. Supplying --env=<name> changes the generated filename to .env.<name>.example.
LPM CLI also validates the resolved environment before lpm run, lpm dev, file execution, and lpm exec. For one run, --no-env-check skips value checks and defaults. Invalid schema declarations still stop the command.
See the LPM CLI lpm.json reference for every schema rule.
Initialize Existing Projects
lpm env init
lpm env ls
lpm env init scans the environment configuration and conventional .env files. It imports files into missing vault environments and leaves environments that already contain secrets unchanged. --force allows those existing values to be replaced.
lpm env ls shows known environment names, stored-value counts, schema coverage, aliases, and the project-level cloud-sync status.
Where Local Data Lives
| Platform | Local storage |
|---|---|
| macOS | Project vault data in Keychain under dev.lpm.vault |
| Linux | Encrypted file at ~/.lpm/vaults/<vault-id>.enc; data key protected by Secret Service when available |
| Windows | Encrypted file at ~/.lpm/vaults/<vault-id>.enc; data key protected by Credential Manager |
When LPM CLI creates a project vault, it records a stable identifier in lpm.json:
{
"vault": "7f3a1e2c-5b9d-4a8f-b6c1-9b1d2e3f4a5b"
}
The identifier is an opaque pointer, not a secret. Commit lpm.json so the project keeps the same vault identity after it is moved or cloned. Removing the field creates a new identity on the next operation that needs a vault; it does not delete the previous local or cloud data.
Upgrade Existing Env Schemas
Encrypted values continue to sync when project metadata is invalid.
The server drops invalid environment entries and their dependent inheritance chains.
If a schema unit is invalid, the server retains the last valid envSchema and envSchemaConfig together.
Updated clients show env_metadata_dropped warnings after successful personal and organization pushes.
In JSON output, each metadata warning contains code, message, and hint.
Released CLI v0.79.0 and app v1.0.1 still sync values, but cannot show this success warning.
The project dashboard shows a recovery banner for all clients.
The activity log records the safe reason, time, and client version without rejected values.
- Update the CLI or app.
- For a public framework prefix such as
VITE_, addclient: trueto the rule. - For a secret rule, remove
defaultandenumliterals fromlpm.json. - Keep secret values in the encrypted environment.
- Use valid canonical environment names with ASCII letters, numbers, hyphens, underscores, or dots, up to 64 characters.
- Avoid reserved names, consecutive dots, and control characters in file paths.
- Correct invalid patterns, empty enums, default values that fail their rules, and incompatible bounds.
- Run
lpm env checkwith the updated client. - Push again to update the metadata and clear the warning.
A client upgrade does not change declarations automatically. Authorization, ciphertext validation, and revision conflicts still block writes.
See Also
- Per-Environment Scoping — Separate development, staging, and production values.
- Cloud Sync — Encrypt and synchronize the complete project vault.
- LPM CLI environment reference — Complete command and output reference.