Skip to main content
Start here if you want the best first live Keycli wedge. This is the current public wedge: one scoped Vercel project → preview env var mutation → hosted apply + audit Why Vercel first:
  • one provider
  • project scope is clear
  • preview-safe path exists
  • low-risk first run

​
What is live

  • create a Vercel connection
  • test project access
  • mutate Vercel env vars through the API
  • redeploy the latest deployment when a plan includes deployAfter: true

​
What to run

​
1. Start the hosted API

​
2. Run the public Vercel preview CLI wedge

Repo-first today means using the repo launcher:
connect vercel is token-backed today. Keycli records the connection with authMethod: "api_token" and immediately tests Vercel account + project access; there is no OAuth flow in this repo yet. If you prefer flags instead of env vars, use:
If you install a launcher later, the same shape is:
You want:
  • readiness output that stays explicit about live vs simulated behavior
  • a low-risk preview plan
  • plan.execution.mode: "provider-api"
  • a succeeded hosted run
  • audit output showing connection creation, readiness check, plan creation, and apply
demo:vercel:preview remains the current internal proof harness for this same wedge. It is useful because it is narrow, repeatable, and good for regression-proofing the preview-safe path, but it is no longer the primary public flow to teach first.

​
If it is not live

Keycli should stay explicit and fall back to simulation when:
  • the connection is missing
  • the token is invalid
  • the project scope does not match

​
Use Vercel for this

Use Vercel when you want:
  • the cleanest first live demo
  • one provider only
  • a preview-safe change before broader rollout

​
Next reads