The TinaCMS CLI

Available Commands

Common options

Here are some common options that can be used in both tinacms dev and tinacms build

Basic Usage:

"tinacms dev"

To run this command, you must have a valid tina/config.{ts,tsx,js,jsx} file.

dev will compile the schema into static files, generate typescript types for use in your project and start a graphQL server on http://localhost:4001

This command takes the arguments listed in the common options

"tinacms build"

This command compiles and validates the schema and generates the client and types. It will also ensure your content has finished indexing.

Options

This command takes all the common options as well as a few others:

Examples:

Building for production with TinaCloud for data fetching

Building for production with a SSG

Using the local client and local graphql server

This will

• Start the local graphql server
• Generate the local TinaCMS client that will query the local file system
• Produce local image paths
• build production SPA
• run Next build

Building from local content with a TinaCloud production client

This will

• Index your content into a temporary in-memory data layer for the duration of the build
• Generate the production TinaCMS client (so the deployed site still talks to TinaCloud at runtime)
• Make zero TinaCloud Content API requests during the build
• Run your framework's build command

Useful when SSG is generating thousands of pages. On SSW Rules (~4,000 pages) build time dropped from 4:55 to 2:12, with TinaCloud Content API calls dropping from ~4,000 to 0.

Because the generated client is the production client, branch, clientId, and token must be configured in your TinaCMS config, the same values you would use for a normal tinacms build.

A few things to know:

• Search indexing is skipped during the build (a warning is emitted). Reindex separately if you rely on search.
• TinaCloud validation checks (branch status, schema match) still run; pass --skip-cloud-checks to skip them.
• If both --local and --content=local are passed, --local takes precedence.

"npx @tinacms/cli@latest init"

The init command must be run inside of an existing project (E.g a NextJS project, Hugo, Jekyll, etc).

This will:

• Install all required dependencies for TinaCMS.
• Define a basic content schema in the tina directory.
• Create example content in the demo directory.
• Edit the package.json to have the dev, build, and start scripts run the tina GraphQL API.

Options

"tinacms audit"

The audit command is used for checking for errors in your in your files. It currently does two things.

• Checks to see if the files have the correct extension
• Submits each file as a Graphql mutation and checks for Graphql errors

By default the mutation will not change the content of the files.

Options

"tinacms search-index"

This command builds the search-index using the content in your repository and uploads it to TinaCloud.

"tinacms doctor"

The doctor command checks whether the TinaCMS packages installed in your project are current against the npm latest dist-tag. It answers the question "am I current?" — the CLI counterpart to the /versions page.

The command:

• Reads your package.json and resolves installed versions from node_modules or your project lockfile (supports package-lock.json, pnpm-lock.yaml, and yarn.lock).
• Filters to the TinaCMS package family: tinacms, @tinacms/*, tinacms-*, next-tinacms-*, and create-tina-app.
• Fetches dist-tags.latest from registry.npmjs.org for each installed package in parallel.
• Prints a table of declared, installed, and latest versions with a status column (CURRENT, OUTDATED, LOCAL, or UNKNOWN).
• Exits with code 1 if any package is outdated or cannot be resolved, so it's CI-friendly.

Options