> ## Documentation Index > Fetch the complete documentation index at: https://docs.kelviq.com/llms.txt > Use this file to discover all available pages before exploring further. # Kelviq CLI > Pricing-as-code for Kelviq — define your products, features, and plans in TypeScript and sync them with your account from the terminal. **The Kelviq CLI is in beta.** It's fully functional — and safe by design, with previews and confirmations before every write — but commands, flags, and the `--json` output shape may still change between releases. Pin an exact version in CI and review the release notes before upgrading. The Kelviq CLI (`@kelviq/cli`) lets you manage your pricing catalog as **code** instead of dashboard clicks. Your products, features, plans, entitlements, and prices live in a single typed TypeScript file — `kelviq.config.ts` — that you can review, diff, and version-control like the rest of your codebase. ```ts theme={null} import { product, feature, plan } from '@kelviq/cli/config'; export const app = product({ identifier: 'my-app', name: 'My App', taxCode: 'saas', }); export const seats = feature({ identifier: 'seats', name: 'Seats', type: 'CUSTOMIZABLE', }); export const pro = plan({ identifier: 'pro', name: 'Pro', product: 'my-app', entitlements: [{ feature: 'seats', value: 5 }], }); ``` The loop is complete in both directions: `kelviq pull` turns a live environment into a config file, and `kelviq push` deploys a config file back — with a diff preview, draft-first writes, and explicit gates before anything customer-facing changes. `kelviq promote` moves your whole sandbox catalog to production the same way. *** ## Why pricing-as-code? Your pricing model decides what customers are billed, what features they can reach, and what limits they hit. It is production infrastructure. But when it lives only in a dashboard, it's managed unlike any other production infrastructure you run: * **Changes are invisible to your engineering workflow.** A plan edit doesn't show up in a pull request, doesn't get a review, and doesn't appear in `git log`. The first your team hears of it may be a support ticket. * **There's no meaningful diff.** "What exactly changed in our Pro plan last quarter?" has no good answer when the only record is the current dashboard state. * **Environments drift silently.** Sandbox and production start identical and slowly diverge — a limit tweaked in one, a price fixed in the other — until "it worked in sandbox" stops meaning anything. * **The model lives in people's heads.** Understanding your own packaging means clicking through screens, plan by plan, feature by feature. A `kelviq.config.ts` under version control changes each of those: | Without | With pricing-as-code | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Dashboard edits leave no trail | Every change is a commit — author, date, diff, and the PR discussion that approved it | | Pricing changes skip review | Pricing changes go through the same pull-request review as any other production change | | Sandbox/production drift is invisible | Pull both environments and `diff` them — drift is a one-command check | | The catalog is spread across dashboard screens | The whole monetization model is one readable file — onboarding is "read this" | | Mistakes surface at runtime, via the API | The file is **typed**: a misspelled field or invalid enum is a compile-time error with a "did you mean" suggestion, before Kelviq ever sees it | The concepts in the file map one-to-one to Kelviq's own — products, features, plans, entitlements, prices. If you know the [core concepts](/quickstart/core-concepts), you already know the format. *** ## What you can do today ### Put your catalog under version control If you've already built your pricing in the dashboard, one command gets it into git: ```shell theme={null} kelviq pull git add kelviq.config.ts && git commit -m "Snapshot pricing catalog" ``` From here on, re-running `kelviq pull --force` and committing captures every catalog change as a diff. Run it on a schedule in CI and dashboard edits stop being invisible — they become commits your team can read. ### Catch drift between sandbox and production Pull both environments and compare: ```shell theme={null} kelviq pull -o sandbox.config.ts --force kelviq pull --prod -o production.config.ts --force diff sandbox.config.ts production.config.ts ``` Because the config format references everything by stable `identifier` slugs — never per-environment UUIDs — the two files are directly comparable. A clean diff means your environments genuinely match; anything else shows you exactly where they don't. Run it before a launch, after a migration, or whenever "it worked in sandbox" needs verifying. ### Review pricing changes like code — then deploy them Propose a pricing change by editing `kelviq.config.ts` in a pull request — the reviewer sees exactly what changes: the new limit, the removed entitlement, the price that swapped. After the merge, deploying is one command with a preview built in: ```shell theme={null} kelviq push --dry-run # exactly what would change, zero writes kelviq push # apply as drafts, after showing the diff and asking kelviq push --publish # and publish the changed plans, after a second confirmation ``` Everything push writes is a **draft** by default — nothing a customer sees changes until you publish, and migrating existing customers to new entitlements or pricing always requires its own explicit flags. Pricing changes get the full GitOps treatment: PR → review → merge → push, with the dashboard as a viewer rather than the editor. ### Promote sandbox to production Build and test your pricing in sandbox, then move it to production in one reviewed step: ```shell theme={null} kelviq promote --dry-run # read-only: exactly what production would change kelviq promote # apply it, drafts first, confirmation required ``` Promote matches resources across environments by identifier — no files, no UUID bookkeeping — and inherits every one of push's safety rails. ### Give your AI tools your pricing model A typed, self-contained TypeScript file is something coding assistants are genuinely good at working with — ask one to "add a Team plan between Pro and Enterprise with 25 seats" and the builders' types keep it honest; anything invalid fails to compile. Pair the CLI with the [Kelviq MCP server](/guides/mcp-server) and your assistant can read the config for context *and* apply catalog changes through the API today. ### Start a new project from a template ```shell theme={null} kelviq init ``` Writes a starter `kelviq.config.ts` to edit by hand — useful when you're designing pricing for a new product and want to sketch the model in code (with autocomplete and validation) before anything exists in Kelviq. *** ## How it fits with the rest of Kelviq Each Kelviq surface has a distinct job — the CLI doesn't replace the others: | Tool | Use it for | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **CLI** (this) | Managing the **catalog itself** — the definition of your products, features, plans, and prices — as versioned code. | | [Dashboard](https://app.kelviq.com) | Visual management, analytics, customer operations, feature renames — and reviewing the drafts push creates. | | [Backend](/backend-integration/node-sdk) & [frontend SDKs](/frontend-integration/react-sdk) | Your **application's** runtime integration — checkouts, entitlement checks, usage reporting inside your product. | | [MCP server](/guides/mcp-server) | Driving the Kelviq API conversationally from Claude, Cursor, or any MCP client. | | [REST API](/api-reference/introduction) | Everything, programmatically — the layer all of the above are built on. | A useful rule of thumb: SDKs are how your **product** talks to Kelviq at runtime; the CLI is how your **team** manages what Kelviq is configured to sell. *** ## Installation Requires Node.js 18 or newer. ```shell theme={null} npm install -g @kelviq/cli ``` Verify the install: ```shell theme={null} kelviq --version ``` *** ## Quickstart ### Step 1: Authenticate ```shell theme={null} kelviq login ``` `login` opens the dashboard's [API keys page](https://app.kelviq.com/settings/api-keys) in your browser and prompts you to paste a **Server API Key**. Input is masked and the key is stored locally with owner-only file permissions. The CLI targets your **sandbox** environment by default. To store a production key too, run `kelviq login --prod`. See [Environments & authentication](/cli/environments) for how keys are stored and how to use environment variables instead (for example, in CI). ### Step 2: Pull your catalog ```shell theme={null} kelviq pull ``` `pull` fetches your sandbox catalog — products, features, plans, entitlements, and prices — and writes it as a `kelviq.config.ts` in the current directory. If you've already set up pricing in the dashboard, this is the fastest way to get it under version control. ### Step 3: Or start from scratch ```shell theme={null} kelviq init ``` `init` writes a starter `kelviq.config.ts` you can edit by hand. The file is plain TypeScript with full autocomplete — misspell a field and the compiler tells you before Kelviq ever sees it. ### Step 4: Check where you're pointed ```shell theme={null} kelviq env ``` Prints which environment the CLI targets and which keys are configured — useful before any command that touches your account. ### Step 5: Make a change and deploy it Edit the config — bump a limit, add a plan — then: ```shell theme={null} kelviq push --dry-run # see exactly what would change kelviq push # apply it as drafts, after confirmation ``` When you're happy, `kelviq push --publish` makes the changed plans live, and `kelviq promote` carries the whole catalog from sandbox to production. *** ## The commands | Command | What it does | | ------------------------------------------------ | ------------------------------------------------------------------------------------------- | | [`kelviq init`](/cli/commands#kelviq-init) | Write a starter `kelviq.config.ts`. | | [`kelviq login`](/cli/commands#kelviq-login) | Paste and store a Server API key. | | [`kelviq logout`](/cli/commands#kelviq-logout) | Remove stored API keys. | | [`kelviq env`](/cli/commands#kelviq-env) | Show the configured environment and key status. | | [`kelviq pull`](/cli/commands#kelviq-pull) | Write your remote catalog to `kelviq.config.ts`. | | [`kelviq push`](/cli/commands#kelviq-push) | Deploy a `kelviq.config.ts`: diff, confirm, draft-first writes, optional publish and prune. | | [`kelviq promote`](/cli/commands#kelviq-promote) | Move the sandbox catalog to production with the same preview and gates. | See the full [command reference](/cli/commands) for every flag, and the [`kelviq.config.ts` reference](/cli/kelviq-config) for the file format. *** ## What's coming * **Catalog browse commands** — list and inspect products, features, and plans without a full pull. * **Browser-based login** — a pairing flow that mints a scoped key from your dashboard session, replacing paste-a-key.