Platform Integrations

Push your decrypted vault to deployment platforms — without LPM ever transmitting plaintext through its own server. The CLI pulls the encrypted blob from cloud sync, decrypts it locally, and sends the plaintext directly to the platform's API (Vercel's REST API, AWS SSM via SDK, etc.). The lpm.dev server stores the platform credential (encrypted with AES-256-GCM, format iv:encrypted:tag) plus a connection config — never the secrets themselves.

Platform sync requires a Pro or Org plan.

Supported platforms

PlatformUse case
vercelPush env vars to a Vercel project
netlifyPush to a Netlify site
coolifyPush to a Coolify-hosted application
flyPush to a Fly.io app
railwayPush to a Railway project
github-actionsPush as encrypted GitHub Actions secrets
aws-ssmPush to AWS Systems Manager Parameter Store
aws-smPush to AWS Secrets Manager
genericPush to any custom HTTPS endpoint

This is the complete list — every platform shown in the dashboard is wired end-to-end. There are no advertised-but-unimplemented options.

CLI surface

lpm env connect <platform> --project=<id>              # link a platform project
lpm env push --to vercel                                # push current env to Vercel
lpm env push --to vercel --env=production --clean       # replace platform values
lpm env pull --from vercel                              # pull from a platform
lpm env status                                          # show connected platforms

--clean replaces all values at the destination instead of merging. Without --clean, the push is additive: new keys are added, existing keys are updated, keys present at the destination but absent locally are left untouched.

--env=<name> selects which local environment to push. Each platform connection can target a different destination environment — --env=production locally can land in Vercel's production environment, Fly's default, or wherever the connection was configured to write.

Dashboard surface

Most platform connect flows are OAuth-heavy (Vercel, Netlify, Railway use OAuth) and they live in the dashboard under each vault's Integrations tab. The dashboard flow:

  1. Click Connect a platform.
  2. Authorize the platform via OAuth.
  3. Pick the target project and destination environment.
  4. Optionally trigger an immediate push from the dashboard, or use lpm env push --to <platform> from the CLI.

Once connected, both the CLI and the dashboard can trigger pushes against the same connection.

How the data flows

[your machine]                       [lpm.dev]                  [platform]
                                                                  Vercel
 cloud blob ←── decrypt ← keychain
       │                              (stores connection
       │                               config + encrypted
       │                               platform credential —
       │                               never the secrets)
       ▼ decrypted in memory
 fetch platform API ────────────────── via lpm.dev metadata ────→ writes envs
       │ (plaintext, TLS to platform)

The lpm.dev server is in the loop only to store the platform credential (the API token or OAuth refresh token used to authenticate to the platform's API) and to look up the connection config when the CLI initiates a push. The plaintext secret never reaches lpm.dev's storage.

The platform credential itself is encrypted at rest with iv:encrypted:tag AES-256-GCM. Rotating it (revoking on the platform side, re-authorizing on lpm.dev) is the recommended path after offboarding someone who could have read the connection.

API surface

EndpointPurpose
POST /api/vault/platforms/connectSet up a new connection
POST /api/vault/platforms/pushTrigger a push (your machine does the decryption + upload)
POST /api/vault/platforms/pullPull from the platform back into your local vault
GET /api/vault/platforms/statusLast-push timestamp per platform

You don't call these directly in day-to-day use; the CLI and dashboard wrap them.

Pull from a platform

lpm env pull --from vercel                 # adopt platform values into the local vault

This is the reverse direction: read the destination's current env, decrypt the platform credential server-side, fetch the platform's env via its API, and write the values into the local LPM vault. Useful when a platform is the source of truth (someone edited a Vercel env directly) and you want to capture the diff before re-pushing through LPM.

What --clean does

ModeBehavior
DefaultMerge. Local keys overwrite matching platform keys. Platform-only keys are kept.
--cleanReplace. The platform environment is wiped and rewritten from the local vault. Platform-only keys are lost.

Use --clean when LPM should be the single source of truth and you want to drop drift. Use the default when LPM owns some keys and humans manage others on the platform.

CI hint

For runtime decrypt inside CI (instead of pushing values to a platform at deploy time), use OIDC for CI. The OIDC flow keeps secrets out of the platform UI entirely — they're decrypted into CI's process env on every run.

The two patterns compose: push to Vercel for runtime, and pull via OIDC in CI for tests + build steps that need the same values.

Plan

CapabilityFreeProOrg
Platform sync—✓✓
Org-scoped connections——✓

A free account that calls lpm env push --to <platform> gets 403 Platform sync requires a Pro or Org plan.

Next