Deploying Environment-Specific Studios

With our datasets and environment files in place, let's now walk through the process of deploying separate Sanity Studios for each environment and setting up the proper CORS origins.

First, we'll need to configure the subdomain for our Studio deployments. Sanity CLI will either use the studioHost option in sanity.cli.ts, if it's provided, or prompt for a hostname in the terminal.

Like our project ID and dataset, we can use an environment variable to configure the hostname for our Studio deployment. So let's add a new environment variable, SANITY_STUDIO_HOSTNAME, to our .env file:

# Warning: Do not add secrets (API keys and similar) to this file, as it source is controlled!
# Use `.env.local` for any secrets, and ensure it is not added to source control

SANITY_STUDIO_PROJECT_ID="[your-project-id]"
SANITY_STUDIO_DATASET="development"

# [hostname].sanity.studio
HOSTNAME="[your-hostname]"
SANITY_STUDIO_HOSTNAME="$HOSTNAME"

Then in your .env.development file add:

# https://www.sanity.io/docs/environment-variables
# Warning: Do not add secrets (API keys and similar) to this file, as it is source controlled!
# Use `.env.local` for any secrets, and ensure it is not added to source control

SANITY_STUDIO_DATASET="development"

# [hostname]-development.sanity.studio
SANITY_STUDIO_HOSTNAME="${HOSTNAME}-development"

Now let's add a studioHost option and set it to the value of our new environment variable:

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  api: {
    projectId: process.env.SANITY_STUDIO_PROJECT_ID!,
    dataset: process.env.SANITY_STUDIO_DATASET!,
  },

  studioHost: process.env.SANITY_STUDIO_HOSTNAME!,

  // ...
})

Now that we've setup our environment variables and configured our CLI and Studio configuration files to read from them, we need a way to target a specific environment.

Sanity CLI will load your environment variables in a predictable order, which we have leveraged to set environment variables for our different modes (production vs. development). .env will be loaded in all modes, so we'll use it as our fallback and add development-specific overrides. For example, we've overridden SANITY_STUDIO_DATASET and we've suffixed HOSTNAME to set SANITY_STUDIO_HOSTNAME.

When running Sanity CLI, you can specify the intended mode for your commands. Commands like build and deploy will run in production mode by default. To target a different environment, you can set the mode by specifying SANITY_ACTIVE_ENV in your terminal:

# builds Sanity Studio in `development` mode, loading `.env` and then `.env.development`

SANITY_ACTIVE_ENV=development npm run build

Now let's deploy our two Studio environments:

# Deploy the development Studio
SANITY_ACTIVE_ENV=development npm run deploy

# Deploy the production Studio
npm run deploy

The last step will be to add your Studio environments to your CORS origin. Navigate to the Studio URL's that you've just created. If they haven't yet been added as CORS origins, you'll be prompted to add them to Manage. You can also either run npx sanity manage from your terminal or open Manage in your browser directly. Navigate to the 'API' tab and add your Studio URL's as origins with credentials allowed.

Congratulations—you now have separate, environment-specific Studios configured and deployed! This setup gives your team the freedom to iterate safely in development while keeping production stable for content editors. Up until now, you've been running CLI commands manually, carefully passing the right environment mode. With everything now structured and standardized, you're ready to take the next step: automating your deployment. In the next lesson, we’ll connect these pieces into a CI/CD pipeline that streamlines your workflow and eliminates manual steps.