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.
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 onserver{ hostname?: string, port?: number }
Defines the
hostname
andport
that the development server should run on.hostname
defaults tolocalhost
, and port to3333
.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 settingSANITY_STUDIO_REACT_STRICT_MODE="true"|"false"
. It only applies tosanity dev
in development mode and is ignored insanity build
and in production. Defaults tofalse
.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.
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.
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 verbosesanity dataset import production.tar.gz dev
More verbose, returning all debuggers in the sanity
namespaceDEBUG=sanity* sanity dataset import production.tar.gz dev
Most verbose, returning all debuggersDEBUG=* 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.