Cloud Sync

Personal cloud sync lets a Pro account store an encrypted project vault in LPM.dev Registry and restore it from an authorized LPM CLI installation.

lpm login
lpm env push
lpm env diff
lpm env pull

Organization vaults use the related sharing workflow described in Org Sharing.

What Push Does

lpm env push requires a non-empty local vault. Before uploading, LPM CLI:

  1. Collects every non-empty named environment.
  2. Generates fresh randomized content-encryption material.
  3. Encrypts the complete environment payload locally with AES-256-GCM.
  4. Wraps the content key with wrapping-key material held by the local installation.
  5. Sends the ciphertext, wrapped key, and non-secret project metadata to LPM.dev Registry.

The interactive command asks before replacing the cloud state:

lpm env push

Automation can confirm explicitly:

lpm env push --yes

Each successful push creates a new Registry version even when the plaintext values did not change. LPM CLI records the version it observed under lpm.json > vaultSync for later conflict detection.

What Pull Does

lpm env pull downloads the encrypted payload, verifies the successful Registry response, unwraps the content key, and decrypts the vault locally.

For a personal vault, pull is an exact replacement:

  • Remote environments replace the complete local environment map.
  • Local-only environments are removed.
  • Local-only keys in an environment are removed.
  • Remote values become the local values.

The interactive command asks before making that replacement:

lpm env pull

Use lpm env diff or export a local backup before pulling when the machine contains changes you still need.

Compare Before Synchronizing

lpm env diff
lpm env diff staging
lpm env diff staging production

The first two forms compare local and cloud key sets. The two-environment form is local-only. Diff reports which keys were added, removed, changed, or left unchanged without printing their values.

Version Conflicts

LPM.dev Registry uses the last version observed by the local project as a compare-and-swap guard. A push is rejected when the cloud vault has advanced since that version:

local project last saw v3
cloud vault is already v4
push is rejected with a version conflict

Review or preserve the local changes, pull the latest cloud copy, reapply the intended values, and push again.

LPM CLI supports a force overwrite for deliberate recovery, but that bypasses the version guard. See the LPM CLI environment reference before using it.

What LPM.dev Registry Stores

For ordinary personal sync, the Registry stores:

  • The encrypted environment payload.
  • The wrapped content key.
  • A project name used in the dashboard.
  • Environment schema and configuration metadata from lpm.json.
  • The sync version, owner, and timestamps.

Project names, environment names, schema rules, and key names included in schema metadata are not encrypted as secret values. The environment values inside the vault payload are encrypted before upload.

Successful sync responses are signed for the authenticated LPM CLI session and verified before the response is parsed or decrypted.

Personal Sync and Other Devices

The personal wrapping key belongs to the local installation and is stored in its system keyring, with a protected file fallback where necessary. A fresh LPM CLI installation that does not have that key cannot decrypt an existing personal cloud vault merely by signing in.

Dashboard Pairing transfers protected wrapping-key material to a browser session so that browser can open the vault. It does not pair a second LPM CLI installation.

Organization sharing solves multi-user access differently: the vault content key is wrapped separately for each authorized member's public key.

OIDC Changes the Trust Boundary

Normal cloud sync is end-to-end encrypted: LPM.dev Registry stores the encrypted payload but does not hold the local wrapping key needed to decrypt it.

OIDC CI pull is an explicit exception. When a Pro user enables an OIDC policy, LPM CLI escrows protected wrapping-key material with the Registry. After a workflow proves its identity and matches the policy, the Registry:

  1. Decrypts the vault on the server.
  2. Selects the authorized environment.
  3. Returns that plaintext environment to the CI job over TLS.

This mechanism is opt-in per personal vault. It is not currently available for organization vaults. Read OIDC for CI before enabling escrow.

The Registry binds each escrow ciphertext to its server-key version, env project ID, and account ID. This binding prevents reuse in another project or account.

The Registry can rotate the server key. The encrypted env data and its policy do not change. OIDC pulls continue after the rotation.

See Also