Skip to main content

Docs home

Keycli is the trust layer between autonomous coding agents and production systems. The fastest way to understand the product is not to read every internal spec. It is to move through one clear path:
  1. understand the model
  2. run the hosted self-demo
  3. connect one scoped provider
  4. make one governed change
  5. inspect approval and audit behavior

The self-serve path

1) Start with the shortest honest proof

Run Quickstart first. That gives you the best first answer to: is Keycli actually doing anything real yet? You will see:
  • plan creation
  • risk + next action
  • approval boundaries
  • apply flow
  • audit output

2) Learn why the product exists

Read Why Keycli if you want the product model in plain English:
  • why agents should not mutate providers directly
  • how Keycli normalizes plan → approval → apply → audit
  • where live-vs-simulated execution shows up

3) Connect a provider

Use Provider connections once you want a live provider path instead of simulation. Recommended first connection: Vercel preview.

4) Make the first governed change

Follow First governed change to see the two important modes:
  • low-risk change that can apply directly
  • approval-gated change that must stop and wait for a human

5) Understand approvals, demos, and integration surfaces

After that, the next pages are:

What is real today

  • Hosted TypeScript control plane with auth, plans, approvals, runs, audit, and provider readiness.
  • Live provider mutation for Vercel, GitHub Actions, and Render when a valid scoped connection exists.
  • Mixed-provider execution when every targeted provider is supported and connected.
  • Narrow GitHub-native approval capture through issue/PR comments.
  • HTTP API as the canonical surface, with MCP as a thin adapter over the same service logic.

What is still early

  • Full GitHub App install flow.
  • Richer policy and scoped permissioning.
  • Rollback and drift detection.
  • Hosted reliability polish beyond the current Postgres + worker seam.
  • Production docs deployment at https://www.keycli.com/docs — the Mintlify source exists in-repo today, but the public subpath rollout is still a planned deployment step, not a shipped claim.

Pick the right first session

I want to understand the product wedge

Start with Quickstart, then Why Keycli.

I want to prove live provider mutation

Go from Quickstart to Provider connections, then use the Vercel deep dive.

I want to evaluate the strongest current wedge

Read GitHub after the Vercel preview path. That is the strongest current mixed-provider story, but it is not the lowest-friction first run.

I want to understand how Keycli should run itself

Read Dogfooding and deployment, then the deeper deployment plan for serving Mintlify at /docs.

Docs map

Onboarding

Integration and operations

Deeper reference

If you are brand new, do not start with the deep dives. The product lands much faster if you go through the onboarding path first.