Organization Sharing | LPM.dev Docs

Organization sharing stores one encrypted project vault in LPM.dev Registry and wraps its content-encryption key separately for each organization member who has registered a sharing key.

Private X25519 keys stay on members' LPM CLI installations. LPM.dev Registry stores their public keys, the shared encrypted vault, and one wrapped content key per included member.

Organization sharing requires an Organization or Enterprise plan. Active billing and the billing grace period allow normal reads and writes. After the grace period, LPM.dev Registry returns HTTP 402 with ORG_BILLING_LAPSED for organization env access until billing is restored.

Cleanup remains available while billing is lapsed. Owners and admins can delete an organization vault, disconnect platform integrations, revoke existing policies or credentials, and remove wrapped member access needed to recover or close the account.

An organization owner or admin can create the first shared copy:

lpm env share --org acme

LPM CLI:

Registers the caller's X25519 public key when the account does not have one yet. This requires step-up authentication.
Retrieves the current organization members and their registered public keys.
Generates a fresh AES-256 content key and encrypts the complete local environment vault.
Wraps that content key separately for every member who currently has a public key.
Uploads the encrypted vault and wrapped member keys to LPM.dev Registry.

Members without registered public keys are not included in that share. Joining the organization alone does not grant decryptable vault access.

Owners and admins can create a shared vault. Owners, admins, and maintainers can update an existing shared vault.

Give a New Member Access

A new member first needs to register their own sharing key. From the project directory, they can start an organization pull:

lpm env pull --org acme

The first attempt registers the member's public key after step-up authentication, but it cannot decrypt a vault that has not yet been wrapped for that key.

An owner, admin, or maintainer who already has vault access must then share the current vault again:

lpm env share --org acme

The member can now pull:

lpm env pull --org acme

Each organization operation checks whether the local X25519 key matches the public key registered for that account. A mismatched installation is directed to the explicit sharing-key recovery flow instead of silently replacing the server-side key.

Pull and Update

An organization pull merges remote keys into the corresponding local environments:

lpm env pull --org acme

It does not use the personal cloud-vault row, and a plain lpm env pull does not select the organization vault.

After changing the local vault, an authorized member updates the organization copy with the same share command:

lpm env share --org acme

Organization writes use the last Registry version observed by the local project. If another member has already published a newer version, pull the organization vault, reconcile the local changes, and share again:

lpm env pull --org acme
lpm env share --org acme

lpm env share --force does not overwrite an existing organization vault. If the vault exists, pull its current state and reconcile the conflict.

If an owner or admin deleted the remote vault, a bound checkout can recreate it:

lpm env share --org acme --force

The checkout must have the same organization binding and a stored revision checkpoint. The command stops unless the exact remote vault is missing.

The recreated vault starts one revision after the stored checkpoint. Other organization and Registry checkpoints do not change.

lpm env rotate-sharing-key

This interactive recovery command replaces the current member's X25519 keypair. It is intended for cases such as losing the installation that held the previous private key.

Rotating a sharing key invalidates that member's wrapped-key rows across organization vaults. An owner, admin, or maintainer with existing access must run lpm env share --org <slug> again before that member can pull.

This is different from rotating an organization vault's AES content key. LPM CLI does not currently expose a dedicated organization content-key rotation command. A successful share encrypts the current local vault with fresh content-encryption material and rebuilds wrapped keys for members who are eligible at that time.

Member Removal

Removing a person from the organization stops future organization-vault delivery because every pull checks current membership.

It cannot take back plaintext, ciphertext, or key material the former member already downloaded. Re-sharing the current vault produces a new encrypted copy for the remaining registered member keys, but no system can erase data already retained outside LPM.dev Registry.

Audit Visibility

The organization dashboard's Activity tab is available to organization owners, admins, and maintainers. Ordinary and removed members cannot retrieve organization vault audit entries.

Audit retrieval is scoped to the selected organization vault. Reusing the same local vault ID in a personal project or another organization does not combine their entries. lpm env log without an organization selector reads the personal vault only.

Browser Access

Open a shared organization project and complete Dashboard Pairing with the CLI machine that holds your registered sharing key.

Your browser can decrypt values for your current account. Owners, admins, and maintainers can edit values. Other members have read access.

If a member leaves, rotate the affected environment key through the CLI before saving in the browser. If your sharing key changes, pair again.

CI Access

An owner or admin can enable OIDC for CI for this project. This opt-in gives the Registry its current content key for server decryption. It never transfers a member's sharing private key.

Initial setup requires the CLI and --allow-server-decryption. The Access page can then manage policies or disable CI decryption.

Content-key rotation or membership key invalidation disables CI decryption and revokes issued credentials. An owner or admin must enable it again for the current key. Disabling access remains available during a billing lapse.

For command behavior, see the LPM CLI environment reference. For the encryption model, see the LPM CLI vault architecture.