CLIs
The command-line tools I drive services with — Stripe, Clerk, GitHub, Supabase and Vercel — without leaving the terminal.
The service CLIs I keep installed. Each one lets me — and my coding agent — manage a platform from the shell: no dashboard round-trips, scriptable, and easy to hand to an agent that already lives in the terminal.
The shortlist
Stripe CLI
Test webhooks locally, trigger events and call the API from the terminal.
Clerk CLI
Manage users, orgs and config, pull env keys and run guided deploys.
GitHub CLI
PRs, issues, repos, Actions and raw API calls from the shell.
Supabase CLI
Run the full stack locally, manage migrations and generate types.
Vercel CLI
Deploy, run dev, pull env vars and tail logs for Vercel projects.
Stripe CLI
The reason I can build payments without deploying on every change. stripe listen
forwards live webhook events to localhost, and stripe trigger fires realistic test
events on demand — so I can develop the whole checkout-to-fulfilment loop offline.
brew install stripe/stripe-cli/stripe
stripe login
# forward webhooks to your local handler (prints a signing secret)
stripe listen --forward-to localhost:3000/api/webhooks/stripe
# fire a test event
stripe trigger payment_intent.succeeded
# tail request logs and hit the API directly
stripe logs tail
stripe customers list --limit 3Clerk CLI
Clerk is my auth default (it's also what gates the Morpha CLI's pro registry), and the
clerk binary turns that platform into terminal commands: manage users and orgs, pull
API keys into .env, treat instance config as code, and run a guided, resumable
promotion from development to production.
# authenticate, then pull keys into your project
clerk login
clerk env pull
# instance settings as code
clerk config pull
clerk config patch
# authenticated Backend API client + guided deploy
clerk api ls
clerk deploy
clerk deploy status
clerk doctor→ Clerk CLI docs · clerk/cli on GitHub
GitHub CLI
gh keeps the whole GitHub loop in the shell — reviewing and merging PRs, filing
issues, and, crucially, driving Actions and raw API calls. gh api is my escape hatch
for anything the porcelain commands don't cover.
brew install gh
gh auth login
# pull requests and issues
gh pr create --fill
gh pr checkout 123
gh issue list --label bug
# Actions and raw API
gh run watch
gh api repos/{owner}/{repo}/releases --paginateSupabase CLI
When I reach for Supabase, the CLI is how I keep local and remote in sync. supabase start boots the entire stack (Postgres, Auth, Storage, Studio) in Docker; migrations
are version-controlled SQL; and supabase gen types keeps my TypeScript types matched
to the schema.
brew install supabase/tap/supabase
supabase init
supabase start # full local stack in Docker
# migrations
supabase migration new add_posts
supabase db push # apply to the linked project
supabase db reset # rebuild local from migrations + seed
# typed schema + edge functions
supabase gen types typescript --local > lib/database.types.ts
supabase functions serveVercel CLI
This site deploys through Vercel, and the CLI is the fastest path to a preview URL.
Beyond deploy, I use vercel env pull to hydrate a local .env from the project's
environment, and vercel dev to run the platform's routing locally.
npm i -g vercel
vercel login
vercel link # connect the folder to a project
# environments and local dev
vercel env pull .env.local
vercel dev
# ship it
vercel # preview deployment
vercel --prod # promote to production
vercel logs <deployment-url>