CLI reference

The Camplax CLI is camplax (Node 24+). It is not published to npm yet, so npm install camplax does not work today; until it is, everything below is also in the console, the REST API and the MCP endpoint. camplax help prints this same list. The dashboard and the CLI use the same projects and the same deploys — nothing you can do in one is hidden from the other.

Most commands take the project slug from the folder's link (camplax link <slug> writes .camplax/link.json) or from camplax.json; pass the slug positionally — or --project/-p on deploy — to override.

Setup

Command	What it does
camplax login	Sign in — opens a browser to authorise this machine, stores CAMPLAX_TOKEN in the CLI config
camplax login <token>	Sign in by pasting a cx_cli_… token (make one in the console — Account → CLI tokens) or a project API key
camplax whoami	Print the current session as JSON
camplax connect	Add Camplax's MCP server to every AI app on this computer — Claude Code (user scope, so every folder), Cursor, VS Code, Codex, Gemini CLI, Antigravity, Devin Desktop, Zed, opencode, Kiro — and install the Camplax agent skill. Only the URL is written; each app asks you to approve once in the browser, no key. Other servers in each file are kept, a re-run changes nothing, and a file it cannot read is left alone. Claude Desktop, claude.ai and ChatGPT get the exact clicks instead. --agent cursor,codex picks apps, --project <slug> binds one project, --read-only makes a viewer connection, --no-skill, --dry-run, --yes, --json. Needs no sign-in
camplax create [dir]	Scaffold a Plax app (sign-in, notes, server AI); camplax create . writes into the current folder when it is empty or git-only; --force into a non-empty dir
camplax init [name]	Write a camplax.json for this repo (--force overwrites); --app scaffolds the Plax starter into this folder, same as create .
camplax create <dir> --deploy	Scaffold the app and create its hosted project in one step: the folder is linked, camplax.json carries the project name, and the next command is camplax deploy --local. --name <name> names the project instead of the folder; the name is checked before anything is written, so a taken name or a full plan leaves nothing behind
camplax projects create <name> [--slug <slug>] [--json]	Create a hosted project for the folder you are in and link it — writes .camplax/link.json and camplax.json. Needs camplax login; plan limits apply, and a refusal (name taken, project limit reached, no active plan) says what to do in one sentence
camplax link <slug>	Link this folder to an existing project
camplax doctor	Plain-English checks: env, secrets, Plax, sign-in, link
camplax probe [slug]	Live write → read → delete checks of this project's features — see below

Working locally

Command	What it does
camplax dev	Pull the project's environment variables into .env.local and run the start command. The production Postgres password never lands on your laptop — work with production data through camplax db studio
camplax dev --port <n> / --command <cmd> / -c <cmd>	Override the port or the start command
camplax env pull [--file .env.local]	Write the project's vault into a local .env (-f to choose the file)
camplax env push [--file .env]	Upload a local .env into the project's environment variables and restart the app
camplax secrets pull|push	Legacy alias for env pull|push
camplax add <id…>	Install components or plugins into the app (camplax add --list to browse)

env push only accepts UPPER_SNAKE_CASE keys, skips empty values, and never touches keys Camplax manages — DATABASE_URL, DIRECT_URL, BETTER_AUTH_SECRET, anything starting CAMPLAX_. When camplax.json lists env names, push sends only those keys.

Shipping

Command	What it does
camplax deploy [--branch <name>|-b] [--project <slug>|-p] [--json]	Queue a deploy; the default branch goes to production, any other branch to a preview
camplax deploy --local	Upload and deploy this folder without a connected repo — honours .gitignore + .camplaxignore, never ships .git, node_modules or .env*
camplax rollback [deploy-id] [--json]	Re-promote a previous production build without rebuilding (builds from your plan's last 7 / 14 / 30 days, plus the one before the live build). Waits until the old build is serving; exits 1 with the reason if it never gets healthy
camplax import --name <slug> [--site <url>] [--db <postgres-url>] [--repo owner/name] [--json]	Create a project and queue a migration; needs at least one of --site, --db, --repo
camplax logs [--tail|-t] [--filter errors|-f] [--search <q>|-s]	Recent logs, or stream with --tail
camplax db studio	Open the schema editor in the console
camplax db migrate	Retired — prints how to apply migrations with camplax config apply, which runs each pending file once and records it
camplax gen types [--out database.types.ts|-o]	Write TypeScript types from the live schema
camplax open [slug] [--page deploys]	Print and open this project in the console
camplax mcp [--check]	Print how Claude Code, Cursor and other agents connect; --check verifies the stored token. One line also works: npx add-mcp https://camplax.dev/mcp

Checking a live app

camplax probe                      # write → read → delete checks against real features
camplax probe --only database,auth # a subset of checks
camplax probe --json               # machine-readable report; exit 1 if any check fails
camplax probe --strict             # exit 1 when a check skipped, not only when it failed
camplax probe --strict --allow-skip domains,webhooks

Each check prints pass, skip or fail. A skip means the feature is not set up on this project — under --strict, "not checked" counts the same as "not working" unless you allow it.

Run a command once

camplax run npm run seed                                  # on production — asks you to type the project's name
camplax run --env feat-login -- node scripts/backfill.js  # on a preview, by its branch
camplax run "npm run migrate && npm run seed"             # a whole command line, quoted
camplax run --confirm my-app npm run seed                 # production from a script, without the prompt

The command runs once on Camplax, beside the live app, from the release it is serving — with the app's own variables and database. Its output streams to your terminal, and camplax run exits with the command's own exit code (124 when it ran out of time). Pressing Ctrl-C stops following, not the command; its output stays in Logs. Only the project's Owner can run commands, signed in with camplax login — a project key cannot. More in Deploys.

In CI

export CAMPLAX_TOKEN="$CAMPLAX_TOKEN"   # a cx_cli_… token from camplax login
camplax deploy --json                    # parse the queued deploy, no browser involved

--json output and JSON errors with a code make deploy, import and probe safe to drive from a pipeline or a coding agent. The same verbs exist over MCP — see AI agents and MCP.

Environment variables

Variable	Meaning
CAMPLAX_TOKEN	Machine or session token (cx_cli_…) — the way to sign in on CI
CAMPLAX_API_URL	API base (default https://camplax.dev)
CAMPLAX_CONSOLE_URL	Console base (default https://camplax.dev/app)

camplax.json

When camplax.json is present it is the source of truth for the repo — name, region, build (install, command, start), env names, database, cron and domains:

{
  "name": "my-app",
  "region": "iad",
  "build": {
    "install": "pnpm install",
    "command": "pnpm build",
    "start": "pnpm start"
  },
  "env": ["DATABASE_URL", "STRIPE_PRICE_ID"],
  "database": { "branchOnPreview": true },
  "cron": [],
  "domains": []
}

Editors validate it against the published schema at https://camplax.dev/schema/camplax.json — camplax init writes the $schema line for you.

camplax.json as code

The same file can declare the rest of a project's infrastructure, so an agent (or you) can change it in a pull request instead of clicking through the console. Names and shapes only — a secret value never goes in this file.

{
  "$schema": "https://camplax.dev/schema/camplax.json",
  "name": "my-app",
  "env": ["STRIPE_PRICE_ID", "TWILIO_AUTH_TOKEN"],
  "database": { "migrations": "sql/migrations", "tables": ["notes", "orders"] },
  "cron": [{ "name": "digest", "schedule": "0 9 * * *", "path": "/api/cron/digest" }],
  "flags": [{ "key": "new_checkout", "enabled": false }],
  "buckets": [{ "name": "avatars", "public": true }],
  "realtime": {
    "channels": [{ "table": "orders", "events": ["insert"] }],
    "topics": [{ "topic": "chat", "broadcast": true, "presence": true }]
  }
}

Command	What it does
camplax config diff [--json]	Compare the file (and the .sql files in database.migrations) with the live project
camplax config apply [--yes] [--json]	Show the same plan, ask once, then apply exactly that plan

Every line of the plan says what apply will do about it:

Mark	Status	Meaning
+	change	Apply creates or updates it — a cron job, a flag, a realtime channel or topic, a bucket, or a pending migration
~	covered	A declared table is missing, but a pending migration in this plan creates it
!	manual	Needs a person: an env name with no value (set it with camplax env push), a domain that needs a DNS record, a table no migration creates
≠	drift	Exists but differs, and apply leaves it — a flag's on/off is runtime state, so apply only sets it when it creates the flag; a topic that only accepts your server's tokens is never loosened back to any signed-in user
x	blocked	Cannot apply, with the reason — a migration edited after it ran, a migration with a statement it may not contain, no database yet
·	unmanaged	Live but not in the file. Apply never deletes

Migrations run first, in name order, each in one transaction together with its row in _camplax_migrations — the same history and checksum the Plax starter's boot runner uses, so a file applied here is skipped at boot and vice versa. The first failing migration stops the ones after it, and the message names the statement that failed. A file that cannot be applied at all holds back every file after it, so migrations always run in name order. Each applied file is also recorded in the project's schema history, like a change made in the schema editor. Each file already runs in its own transaction, so a BEGIN; … COMMIT; wrapper around the whole file is dropped; otherwise a migration file may not contain transaction control (BEGIN, COMMIT, ROLLBACK, SAVEPOINT), role or permission changes (GRANT, REVOKE, CREATE ROLE, SET ROLE, OWNER TO), COPY, or database-level statements (CREATE/DROP DATABASE, ALTER SYSTEM) — the plan marks such a file blocked and says which statement. Symlinks in the migrations folder are refused. Apply sends the plan's hash and the API refuses (409 plan_changed) if the project changed after you looked. The same plan and apply are the MCP config tool and POST /v1/projects/<slug>/config/plan · /apply.

Topics are compared field by field: only the fields your file sets are checked, so { "topic": "chat" } never resets a live topic's switches, and the plan shows each change as broadcast off → on. A new topic starts with broadcast and presence off.

A production deploy applies the file too, once it is live: the declarative sections — cron, flags, realtime channels and topics, buckets — in the camplax.json that deploy shipped (the commit from GitHub, or the code you uploaded with camplax deploy --local) are reconciled with the same plan/apply, so a pull request that adds a cron job lands it with the deploy. A starter's own file is applied when the project is created. Each version of the file is applied once: redeploying the same file changes nothing, so a cron job or flag you removed in the console stays removed until the file itself changes. Every apply that changed something shows in the project's activity with the list of changes. The same "never deletes, never flips a flag back" rules hold, and migration files still run only through camplax config apply.