👀 See Sanity in action: Watch product demo now →

CLI API

Wrangle datasets and webhooks, initialise plugin boilerplate code, build and deploy—all from the command line

The sanity Command Line Interface (CLI) is a handy tool for managing your Sanity projects in your terminal. Note that there are some commands that can only be run in a project folder and global ones.

Configuration file

Sanity CLI can read configuration from a sanity.cli.js (.ts) file in the same folder that the command is run in.

  • apiCliApiConfig

    Defines the projectId, dataset that the CLI should connect and run its commands on

  • server{ hostname?: string, port?: number }

    Defines the hostname and port that the development server should run on. hostname defaults to localhost, and port to 3333.

  • graphqlGraphQLAPIConfig[]

    Defines the GraphQL APIs that the CLI can deploy and interact with.

  • reactStrictModeboolean

    Wraps the Studio in <React.StrictMode> root to aid in flagging potential problems related to concurrent features (startTransition, useTransition, useDeferredValue, Suspense). Can also be enabled by setting SANITY_STUDIO_REACT_STRICT_MODE="true"|"false". It only applies to sanity dev in development mode and is ignored in sanity build and in production. Defaults to false.

  • viteany

    Exposes the default Vite configuration for the Studio so it can be changed and extended.

  • project{ basePath?: string }

    Contains the property basePath which lets you change the top-level slug for the Studio. You typically need to set this if you embed the Studio in another application where it is one of many routes. Defaults to an empty string.

Commands

usage: sanity [--default] [-v|--version] [-d|--debug] [-h|--help] <command> [<args>]

Commands:
   build      Builds the current Sanity configuration to a static bundle
   codemod    Runs a code modification script
   cors       Interact with CORS-entries for your project
   dataset    Interact with datasets in your project
   debug      Gathers information on Sanity environment
   deploy     Deploys a statically built Sanity studio
   dev        Starts a development server for the Sanity Studio
   docs       Opens the Sanity documentation
   documents  Interact with documents in your project
   exec       Runs a script in Sanity context
   graphql    Interact with GraphQL APIs
   help       Displays help information about Sanity
   hook       Interact with hooks in your project
   init       Initialize a new Sanity studio project
   install    Installs dependencies of the current project
   login      Authenticates against the Sanity.io API
   logout     Logs out of the Sanity.io session
   manage     Opens the Sanity project management UI
   preview    Starts a local web server for previewing production build
   projects   Interact with projects connected to your logged in user
   start      Alias of `sanity preview`
   undeploy   Removes the deployed studio from <hostname>.sanity.studio
   users      Manage users of your project
   versions   Shows the installed versions of Sanity CLI and core components

See 'sanity help <command>' for specific information on a subcommand.

Debugging sanity commands

Not to be confused with sanity debug, which returns information about your Sanity environment, you can use the DEBUG environment variable with your sanity commands to get more verbose results and troubleshoot potential issues.

For full debugger results, use a wildcard on its own (DEBUG=* sanity <command>). For more targeted results, you can specify a namespace followed by a wildcard (DEBUG=sanity* sanity <command> or DEBUG=sanity:cli* sanity <command>).

Example

Least verbose
sanity dataset import production.tar.gz dev

More verbose, returning all debuggers in the sanity namespace
DEBUG=sanity* sanity dataset import production.tar.gz dev

Most verbose, returning all debuggers
DEBUG=* sanity dataset import production.tar.gz dev

Results can also be excluded by using a - prefix. DEBUG=sanity*,-sanity:export* sanity dataset export production production.tar.gz would return all debuggers in the sanity namespace except for sanity:export debuggers (e.g., sanity:cli and sanity:client) during export of the production dataset.

Was this article helpful?