Skip to main content

​
Keycli internal dogfooding + deployment runbook

This runbook is the recommended path for using Keycli on its own landing/deployment stack.

​
Goal

Use Keycli as the trust layer for deployment-related changes, not as raw infra provisioning. That means:
  • create the initial provider resources manually
  • then route secret/config/deploy-linked mutations through Keycli

​
Why this path

Keycli is already strongest at:
  • provider connection testing
  • scoped provider connections
  • plan / approval / apply / audit
  • env var and secret mutation
  • deploy-after-change flows
It is not yet the right tool for:
  • creating all cloud resources from zero
  • full rollback orchestration
  • broad infra lifecycle management

​
Internal stack to dogfood first

  • Vercel → landing site project (apps/site)
  • GitHub → repo-level Actions secrets / approval workflow
  • Render → only if/when we deploy a service there

​
Phase 1 — publish the landing from GitHub

  1. Create/publish the canonical GitHub repo for Keycli
  2. Import that GitHub repo into Vercel with apps/site as the project root
  3. Confirm the public URL works
  4. Configure the landing env vars needed for lead capture / analytics
  5. Treat that deployment as the first real target Keycli will later govern

​
Phase 2 — bootstrap Keycli workspace

Create an internal workspace such as:
  • keycli-internal
  • or keycli-marketing
Create scoped provider connections:
  • Vercel scoped to the landing project
  • GitHub scoped to the exact repo
  • Render scoped to the exact service (only when relevant)
Then:
  1. test each connection
  2. confirm workspace readiness
  3. confirm provider scopes show up correctly

​
Phase 3 — move safe mutations into Keycli

Start with lower-risk actions:
  • preview env var changes
  • analytics config changes
  • webhook/config endpoint updates
  • low-risk deploy-after-change flows
This is the fastest honest dogfooding wedge.

​
Phase 4 — move higher-risk changes behind approval

Once the basic flow is reliable, route these through Keycli:
  • production env var changes
  • API key rotation
  • GitHub Actions secret updates
  • coordinated Vercel + GitHub changes
Require approval for any meaningful prod-facing mutation.

​
Phase 5 — learn from friction

Every awkward internal use becomes product input. Track pain points like:
  • approval flow too manual
  • connection scope confusing
  • policy too weak
  • worker visibility insufficient
  • deploy feedback unclear
  • missing rollback / drift verification

​
What Keycli should govern first

​
Good first governed changes

  • NEXT_PUBLIC_SITE_URL updates
  • analytics toggles
  • guided-help webhook config
  • Resend email config
  • GitHub Actions secrets tied to the landing/deploy workflow

​
Not first

  • full Vercel project provisioning
  • DNS/domain setup automation
  • broad multi-service infrastructure management
If a change mutates provider state for the landing stack and can be represented as:
  • create / update / rotate / delete / deploy
…prefer routing it through Keycli once the relevant provider connection is live.

​
Success criteria

This dogfooding path is working when:
  • the landing is public
  • preview config changes can go through Keycli safely
  • at least one real secret rotation runs through Keycli
  • at least one approval-gated prod change runs through Keycli
  • the audit trail is useful enough to review after the fact