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.

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

PlatformLocal storage
macOSProject vault data in Keychain under dev.lpm.vault
LinuxEncrypted file at ~/.lpm/vaults/<vault-id>.enc; data key protected by Secret Service when available
WindowsEncrypted 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.

  1. Update the CLI or app.
  2. For a public framework prefix such as VITE_, add client: true to the rule.
  3. For a secret rule, remove default and enum literals from lpm.json.
  4. Keep secret values in the encrypted environment.
  5. Use valid canonical environment names with ASCII letters, numbers, hyphens, underscores, or dots, up to 64 characters.
  6. Avoid reserved names, consecutive dots, and control characters in file paths.
  7. Correct invalid patterns, empty enums, default values that fail their rules, and incompatible bounds.
  8. Run lpm env check with the updated client.
  9. 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