@enterprise-skills/launchops-cli

Declarative deployment control plane for Vercel (more vendors landing per release notes). Drives the LaunchOps agent — scan -> diff -> plan -> approve -> apply -> verify — from a YAML manifest, with a tamper-evident audit log on every action.

npx @enterprise-skills/launchops-cli sync           # dry-run
npx @enterprise-skills/launchops-cli sync --apply   # gated apply

Or install globally:

npm i -g @enterprise-skills/launchops-cli
launchops sync --apply

What it does

You declare the desired state of a Vercel project (env vars, attached domains, sources for those env vars) in a manifest:

# infra/launchops/control-plane.manifest.yaml
version: "1"
tenant: my-control-plane
stack:
  hosting:
    vendor: vercel
    project: my-control-plane

env:
  - name: NEXT_PUBLIC_SUPABASE_URL
    source: vercel-project://my-public-site/NEXT_PUBLIC_SUPABASE_URL
    scope: production
  - name: STRIPE_SECRET_KEY
    source: vercel-project://my-public-site/STRIPE_SECRET_KEY
    scope: production

domains:
  - host: control.example.com
    attached_to:
      vendor: vercel

Then launchops sync reads the manifest, scans Vercel via API, computes drift, synthesizes an apply plan, gates each destructive action through an approval queue stored on disk, and runs the apply with a verify pass at the end. Every action — apply, gate decision, verify — is recorded in .project-ai/launchops/audit.jsonl with an integrity hash.

Supported source URI schemes

| Scheme | Resolves to | |---|---| | vercel-project://<project>/<key> | Decrypted env var on another Vercel project (uses ?decrypt=true). Caveat: returns sealed envelopes for team-scoped projects on newer accounts; v0.4 passes envelopes through. | | env://<NAME> | The current process.env.<NAME> (or .env.local after the CLI loads it). |

Approval workflow

When the plan contains a destructive action (env_var delete, domain detach, etc.), the executor writes an approval YAML to .project-ai/launchops/approvals/<action-id>.yaml with status: pending and gates the action. Re-run with --apply after editing the YAML:

status: approved
resolved_at: '2026-05-18T00:00:00.000Z'
resolved_by: <your-name>
reason: <one-line justification>

There is no --auto-approve. There is no --prune-all. These are intentional refusals — the worst class of LaunchOps incident is "the agent deleted a resource it shouldn't have because the approval was implicit." Every destructive action gets an explicit, named, file-recorded approval.

Pruning specific resources

To delete one specific extra_in_vendor resource (an env var or domain that exists on the vendor side but isn't in your manifest):

launchops sync --prune-extra LAUNCHOPS_DEMO_AT --apply

This promotes that single drift from the default review action to delete. Repeat the flag or pass multiple ids after one flag for batch pruning. It is intentionally not wildcardable.

Authentication

Set VERCEL_TOKEN in your shell or in <projectRoot>/.env.local. Get a token at https://vercel.com/account/tokens.

VERCEL_TEAM_ID is optional — v0.4+ auto-detects the team from the manifest's declared project's accountId. Set it explicitly if you want to override or have multiple teams that own different projects.

Architecture

This package depends on:

• @enterprise-skills/launchops-core — vendor-agnostic agent (manifest schema, drift differ, plan executor, approval queue, secret resolver contracts, audit log)
• @enterprise-skills/launchops-adapters — vendor-specific implementations: all six are registered (Vercel, Cloudflare, Stripe, Supabase, GitHub, AWS). Supabase and AWS are scan-only by declaration (supports_apply: false — the executor refuses apply actions for them; AWS writes are OpenTofu-engine territory per the v2 design).

You can use the agent and adapters directly in TypeScript without this CLI — see the core package's exports.

Status

Alpha. Vercel, Cloudflare, and Stripe are validated against live infrastructure (Vercel: env_var + domain, full CRUD lifecycle; Cloudflare: DNS scan + gated create/update/delete; Stripe: products + webhooks scan + gated create/update/delete, dogfooded in a test-mode sandbox — live-mode writes are intentionally left to the operator). GitHub scans live weekly (CI reachability smoke) and authenticates both user tokens and CI installation tokens, but has not applied against live infrastructure. Supabase is scan-only by declaration.

This bin exposes sync only. The full LaunchOps surface — init, scan, diff, plan, apply, approve/reject/approvals, rollback, report, advise, templates, watch — lives in the main CLI as enterprise-skills launch <command> (enterprise-skills). Prefer it for new setups; this bin remains for existing sync pipelines. Note their defaults differ: sync reads infra/launchops/control-plane.manifest.yaml and resolves vercel-project:// secret sources; es launch reads launchops.manifest.yaml and resolves env:// sources.

License

See packaging/LICENSING.md in the source repo.