Skip to main content

​
Dogfooding and deployment

Keycli should dogfood the thing it is already good at: governing production changes after the initial infrastructure exists. That means the recommended path is:
  1. create the base resources manually
  2. connect those resources to Keycli
  3. route config, secret, and deploy-linked mutations through Keycli

​
What to deploy manually first

Today, do these manually first:
  • the marketing/landing app
  • initial provider resources
  • domains and DNS
  • first-pass cloud/project setup
Keycli is not yet pretending to be a full zero-to-cloud provisioning system.

​
What Keycli should govern first

Once the stack exists, Keycli is already a good fit for:
  • preview env var changes
  • production env var changes with approval
  • shared secret rotation
  • GitHub Actions secret updates
  • coordinated Vercel + GitHub changes
  • deploy-after-change workflows on supported adapters

​
Current hosted deployment modes

​
Local demo mode

Good for product demos and rapid iteration.
  • in-memory storage
  • single API process
  • no durable queue

​
Postgres + worker mode

Use this when you want the more honest hosted shape: 
DATABASE_URL=postgres://... npm run db:init
DATABASE_URL=postgres://... npm run api:hosted
DATABASE_URL=postgres://... npm run worker:hosted
Important truth:
  • this is the real durable direction
  • it is still early in reliability polish, retries, and operator ergonomics

​
Internal rollout order

The best internal progression is:
  1. publish the landing manually
  2. create scoped Vercel and GitHub connections for the real project/repo
  3. test readiness
  4. run a preview-safe change through Keycli
  5. move production-facing config behind approval
  6. learn from every awkward step
  • Vercel project for apps/site
  • GitHub repo for Actions secrets and approval workflow
  • Render only when there is a real service there to govern

​
Source docs for operators

These deeper docs remain useful, but they are secondary to the onboarding flow:

​
Honest current status

​
Strong today

  • provider connection setup/testing
  • scoped readiness
  • plan → approval → apply → audit model
  • live provider mutation on the supported slice

​
Still early

  • rollback and drift verification
  • GitHub App install flow
  • broader hosted reliability polish
  • public Mintlify rollout at www.keycli.com/docs

​
Suggested next read

If you are planning the public docs surface, read Serving Mintlify at www.keycli.com/docs.