The krantho CLI

krantho is a command-line client for a running krantho site. Every command that touches content goes through the site's REST API — your local dev server or a deployment — and never reads the database or the content files directly. What you can do from the terminal is exactly what the API allows your role to do.

Two commands are local instead: krantho dev and krantho build run your framework's own dev server and production build.

Build it from source#

The CLI needs Go 1.26 or later. From the root of a krantho checkout:

cd cli
go build -o krantho ./cmd/krantho
./krantho --help

go install ./cmd/krantho builds it into your Go bin directory instead, so krantho is on your PATH when that directory is.

Choose the site#

The CLI talks to one API origin at a time. It takes the first of:

1. the --api-url flag,
2. the KRANTHO_API_URL environment variable,
3. http://localhost:3000.

A trailing / or /api is dropped, so https://example.com/api and https://example.com name the same site.

export KRANTHO_API_URL=https://example.com
krantho info

The commands that call the API also take --json. It prints the server's JSON response as it came, which is the form to use in scripts.

Sign in#

krantho auth login --token "$KRANTHO_API_TOKEN"
krantho auth status
krantho auth logout

auth login first asks the site which auth mode it uses:

• none — there is nothing to store, and the CLI says so.
• token — --token is the site's shared secret (KRANTHO_API_TOKEN). The CLI exchanges it for a session and stores the session, not the secret.
• oidc — --token is a session token you obtained by signing in to the site's admin. The CLI stores it as given.

Sessions are stored per API origin in ~/.krantho/credentials.json, readable only by you. When a stored session has expired, the CLI renews it once with its refresh token and retries; if that fails, it asks you to run krantho auth login again. auth status shows who you are signed in as and with which roles. auth logout removes the stored session for the current origin.

Commands#

Project#

Content#

Field values from --field and set are sent as strings; the collection's schema on the server decides whether they are valid. set sends the version it read, so if someone saved the document in the meantime the server answers with a conflict instead of overwriting their change. create and set save; visitors see the change once you run publish.

krantho content create pages privacy --field title="Privacy" --field description="What krantho.com stores about its visitors." --body privacy.md
krantho content publish pages privacy

The terminal editor#

krantho content edit opens a full-screen editor with the document's fields on top, in the order of the collection's schema, and the Markdown body below. It works like a small vim:

A save asserts the version you loaded, like set, so a concurrent edit surfaces as a conflict on :w.

Schema#

The field types are string, number, boolean, date, enum, url, email, textarea, color and reference. A runtime field adds to a collection; a field defined in code cannot be changed from the CLI.

Export and import#

Checkpoints#

SEO#

seo generate writes sitemap.xml on the server. structured-data.json, faq-pages.json and llms.txt come from the build-time tools, and the result says so — see The SEO pipeline.

seo enrich takes the kind of enrichment to run: meta-descriptions or archetype. The job runs on the server with the site's language model settings and needs the admin role. The CLI prints progress as items complete and a tally at the end, and exits with an error if the job fails or any item does. It stops watching after 30 minutes; the job itself keeps running on the server.

Dev server and build#

Both look in the project directory (--dir, default .) for a framework config file:

The command runs through pnpm exec when the directory has a pnpm-lock.yaml, and through npx otherwise. --dry-run prints the command instead of running it:

krantho dev --port 4002 --dry-run
# pnpm exec next dev --port 4002