Hosting and deployment

How to deploy Sanity Studio, either on your own or using our hosted service.

Sanity Studio is an open-source React-based Single Page Application (SPA) that runs entirely in the browser and connects with Sanity's hosted APIs and Content Lake.

There are two primary ways of hosting Sanity Studio:

• We can host this web application for you, giving you a nice my-company.sanity.studio URL. With a single Sanity CLI command, you can deploy and manage multiple Studios for different environments or use cases under the same project.
• You can deploy Sanity Studio on any hosting platform that supports SPA routing.

The built-in Sanity Studio hosting is the quickest and easiest way to make the Studio accessible on the web. Self-hosting is usually preferred when you wish to use platform-specific features that are not offered by our hosting and when you want to host the Studio under your own domain.

npx sanity@latest deploy

pnpm dlx sanity@latest deploy

yarn dlx sanity@latest deploy

bunx sanity@latest deploy

Running this command from your Studio project folder builds and deploys your Studio, making it available on a *.sanity.studio URL that redirects to the studio inside Dashboard. When you deploy, you will be asked to choose a unique hostname for your Studio.

You will also be prompted to, optionally, add your appId to your client configuration. Doing so will enable fine-grained control of how and when your studio will auto-update in the project management settings.

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  api: {
    projectId: '<your-project-id>',
    dataset: '<your-dataset>'
  },
  deployment: {
    appId: '<your-app-id>',
    autoUpdates: true
  }
})

npx sanity@latest undeploy

pnpm dlx sanity@latest undeploy

yarn dlx sanity@latest undeploy

bunx sanity@latest undeploy

Run the command above to change the hostname later or remove the Studio from the web. You may choose a new hostname the next time you deploy.

The undeploy command targets the studio host defined in your sanity.cli.ts configuration. Use the environment variable strategy in the next section if you wish to enable deploying/undeploying different studio instances.

You can host with Sanity automatically with continuous integration tools. This is convenient for automatically updating the hosted Studio when you push your local changes to source repositories or do manual releases. Add sanity as a development dependency and configure your CI/CD workflow to run the command sanity deploy. Remember to have the sanity.cli.ts config file in your Studio folder.

If you need to accommodate test, staging, and production deployments, then we recommend that you define the appId (and other configuration) in environment variables and access them in the config file like this:

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  api: {
    projectId: process.env.SANITY_STUDIO_PROJECT_ID,
    dataset: process.env.SANITY_STUDIO_DATASET,
  },
  deployment: {
    appId: process.env.SANITY_STUDIO_APP_ID,
    autoUpdates: true
  }
})

You also need to provide an authorization token using the SANITY_AUTH_TOKEN environment variable. This is because deploying with the sanity deploy command uses your local user session for authenticating with our hosting service, which won't necessarily be available in your CI/CD workflows. You can create a deploy token in the project management dashboard.

If your CI/CD pipeline builds the Studio in a separate step, use --no-build to skip the build and deploy the existing dist/ directory:

npx sanity@latest deploy --no-build

pnpm dlx sanity@latest deploy --no-build

yarn dlx sanity@latest deploy --no-build

bunx sanity@latest deploy --no-build

Schema extraction and manifest upload still run during deploy. The dist/ directory must exist before running this command. See Deploy for the full pipeline.

Since the Studio consists of static HTML, CSS, and JavaScript files and communicates with Sanity through our HTTP API, it can be hosted anywhere. Popular hosting services like Vercel and Netlify make it possible to automatically deploy new versions of your Studio when you push it to code repositories like GitHub.

There are two things you need to make sure of when hosting the Studio yourself or with a service:

• The server that delivers the Sanity Studio files needs to be configured for single-page application routing. This means if the requested URL path doesn't exist on the filesystem, it should serve index.html to allow the frontend router to handle the request. Most hosting services will have configuration options for this.
• The domain for where the Studio is hosted must be added as a valid domain in the project's CORS settings. For security, the Sanity API ensures that only approved Studios can communicate with your project. This is in addition to other security measures such as user authentication, private datasets, and custom access rules.

If you host with Sanity, this is automatically handled for you. If your host does not support single-page-application routing, you can add a redirect rule to make sure non-existent paths are redirected properly. Check the documentation for your provider or server software.

Normally, the Studio expects to be hosted at the root level of its hostname; for instance https://studio.example.com/. To serve the studio on a subpath, such as https://example.com/studio, you need to edit the CLI configuration file. You'll find it as sanity.cli.js or sanity.cli.ts in the root of your Studio project.

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  project: {
    basePath: '/studio'
  },
  // ...config continued
})

The Studio can now be served from https://example.com/studio. This will also change the base path of static files.

Most cases where you embed the Studio in another application will require you to set the basePath.

Setting the SANITY_STUDIO_BASEPATH environment variable is an alternative method of defining the base path for the studio, and will override any value set in the configuration file.

npx sanity build

# Specifying the build folder name to be "public"
npx sanity build public

pnpm dlx sanity build

# Specifying the build folder name to be "public"
pnpm dlx sanity build public

yarn dlx sanity build

# Specifying the build folder name to be "public"
yarn dlx sanity build public

bunx sanity build

# Specifying the build folder name to be "public"
bunx sanity build public

Run the command above from the studio folder to generate the files for hosting. This will output the files to the dist/ directory by default. Sometimes your environment requires another directory name, for instance public. You can specify this by entering the desired name after the build command.

Once the build is complete, the directory can be uploaded and hosted from any web hosting where you can control redirects for a Single-Page Application, like Vercel, Netlify, or Cloudflare.

When you use sanity deploy to deploy to Sanity-managed hosting, manifest extraction and schema deployment happen automatically. When you self-host, you need to run these steps separately after building.

Without the manifest, features like the Dashboard, Canvas, and Agent Actions can’t discover your studio or its schema.

After building your studio, extract the manifest and deploy the schema:

npx sanity@latest schemas deploy

pnpm dlx sanity@latest schemas deploy

yarn dlx sanity@latest schemas deploy

bunx sanity@latest schemas deploy

Add these commands to your CI/CD pipeline or build script to keep your schema in sync with each deploy. For details on manifest extraction and schema deployment options, see Schema deployment.

npx sanity@latest deploy --external

pnpm dlx sanity@latest deploy --external

yarn dlx sanity@latest deploy --external

bunx sanity@latest deploy --external

Run the command above from the studio folder to register your studio with Sanity. This will enable your studio and schema to be used across Sanity.

Sometimes you want to configure the projectId , dataset or studioHost specified in sanity.cli.js and sanity.config.js at build time. This is useful for building multiple Studios from the same schema and code to facilitate different environments. See the documentation on environment variables for your options.

Every studio registered to a project is listed on the project's Studios tab in Sanity Manage. The list covers studios deployed with sanity deploy and self-hosted studios registered with sanity deploy --external. Each row links to that studio, and the row's action menu lets you rename it, control whether it appears in Dashboard, and remove it from the project.

The project page in Manage shows a single button for opening a studio. Its destination is a rule rather than a setting, so you can't pin it to a particular studio. Manage resolves it from the studios registered to the project:

• No registered studios: no button appears.
• Exactly one self-hosted studio: Open Sanity Studio opens that studio, no matter how many Sanity-hosted studios are also registered.
• No self-hosted studios and exactly one Sanity-hosted studio: Open Sanity Studio opens that studio.
• Any other combination, such as two self-hosted studios or two Sanity-hosted studios and no self-hosted one: View Studios appears instead and links to the Studios tab.

Because a single self-hosted studio takes precedence, registering one changes where the button goes. This is expected behavior, not a regression. To reach a specific studio regardless of the rule, open it from its row on the Studios tab.

On the Studios tab, open a studio's action menu, click Remove studio, and confirm. Removing a studio de-registers it from the project and can't be undone. To register a self-hosted studio again, run npx sanity@latest deploy --external from the studio folder.

For a self-hosted studio, removing the entry affects the registration only:

• Your hosting keeps serving the studio at its own URL. Your datasets, content, and any in-progress edits are untouched — they live in Content Lake, independent of this list.
• The studio no longer appears in Dashboard, and features that rely on its registered schema — including Content Agent, Canvas, and Agent Actions — can no longer reach it.
• The studio stops counting toward the button rule, which can change what the project page shows.

How to deploy the GraphQL APIs is covered in its own section.