Cred CLI

Overview

This directory contains a simple CLI to create, update, delete, and list projects, packages, and versions in the Credible's Semantic Model Service.

Usage

For complete usage instructions and command reference, see the official documentation at https://www.credibledata.com/docs/platform-admin/cli.

Driving cred from an agent

cred is built to be run by a coding agent (Claude Code, Codex, Cursor) as well as by a person. The contract:

• Every question has a flag. A picker is the human way to answer it; the flag is the other way — cred login <organization> answers the organization picker, cred publish --yes answers the publish confirmation, and cred init -o <org> -e <env> [--create-environment] [--connections all|none|a,b] [--skills replace|keep|none] [--package <dir>] --no-start --no-open runs the whole setup with no prompt.
• Without a terminal, nothing prompts. When stdin is not a TTY, CI or CRED_NON_INTERACTIVE is set (to anything but 0 or false), or --non-interactive is passed, a command that needs an answer exits 2 and prints the flag and the options on stderr, e.g. Cannot ask "Which environment?" without a terminal. Pass --environment <name>. Options: prod-bars, staging. Exit 0 is success, 1 is failure, 2 is "needs input".
• Logs go to stderr; data goes to stdout. cred status --json and cred ls ... print one JSON document you can parse. cred status --json reports organization and environment (what cred publish here would act on: --cell's cell, else the directory's pin, else ~/.cred), deployment, controlPlane, deploymentFrom (flag when --cell chose the deployment, folder when this directory's pin did, else global), ignoredPin (the pin's cell, only when --cell names another), token (valid, kind, expiresInSeconds), and in a directory cred init wired, directory (the pin, with its deployment) and publisher (running, ready, packages, uiUrl, mcpUrl) — or { "error": ... } with exit 1 when it cannot read your setup.
• Every command says where it acts, and acts where the directory is pinned. In a directory cred init set up, org- and environment-scoped commands (ls, get, add, update, rm, publish) use the directory's deployment, organization and environment; elsewhere, ~/.cred's. Each prints Using <org>/<env> on <deployment>, pinned in .credible/config.json. (or from your global settings) on stderr, and every confirmation repeats it. An agent should check that line before anything that changes state. cred set environment always changes the global setting; cred dev -e re-pins a directory. --cell naming another cell than the pin makes reads act on that cell, and makes writes (publish, add connection) and cred dev refuse; cred --cell <cell> init is the explicit re-pin.
• cred publish can be previewed and read back. --dry-run lists the files it would upload (stdout) and the ones it leaves out (stderr), uploads nothing and needs no login. --json prints one document: organization, environment, package, version, url (the version in the app), latest (now, when-built or no), latestVersion, excluded and response (the server's reply as sent). With --dry-run, --json prints dryRun (true), package, version, included and excluded instead. A .credignore beside publisher.json leaves more files out, one path or glob per line (notes.md, tests/, /docs), matched regardless of case (secrets/ also leaves out Secrets/). A nested .credignore is not read, and every file or folder named .credignore, at any depth, is always left out of the upload. It can never put back a file the fixed list leaves out, and a publish stops if it leaves out publisher.json. Warnings the server raises on the publish print on stderr after the link; with --json they are only in response.warnings. cred get version <package> <version> shows whether a version has built (buildStatus) and is waiting to become latest (promoteWhenReady); cred get package <package> shows the latest.
• cred token prints a usable access token and nothing else, renewing it first when it is within two minutes of expiring. It exits 1 rather than print a token that has already expired.
• cred login needs the human once. It prints a URL and a code; relay them and wait — it polls until they sign in.
• cred dev is a foreground process. Start it in the background with --no-open, then poll cred status --json until publisher.ready is true (running alone can be a server whose only package failed to compile).

The three journeys, as commands:

# 1. I run a local Publisher against my own warehouse; move to Credible.
cred init -e my-env --create-environment --connections my_warehouse --no-start
cred dev --no-open &          # then poll: cred status --json
cred publish -y               # publisher.config.json is never uploaded

# 2. I run a local Publisher over CSV / DuckDB files; publish the package.
#    (a create-malloy-package directory: setup serves the package it lists,
#     and --skills says what to do with the scaffolder's skills)
cred init -e my-env --create-environment --connections none --skills replace --no-start
cd shop && cred publish -y    # the data files travel inside the package

# 3. I use Credible and want to model locally with Claude Code.
cred init -e prod-bars --no-start   # skills, .mcp.json, CLAUDE.md, publisher config
cred dev --no-open &                 # local publisher proxies to the real warehouse