Managing Development and Production Environments in Sanity Studio
Great questions! Let me break down how Sanity handles different environments and datasets:
What's in a Dataset vs. Your Code
Datasets contain only your content (documents). Your code - including schemas, Studio configuration, plugins, and all the objects you define - lives in your codebase, not in the dataset. This is an important distinction that gives you flexibility in how you structure your environments.
Setting Up Development vs. Production
You have two main approaches:
Option 1: Multiple Datasets (Recommended for most cases)
The most common pattern is to use different datasets for development, staging, and production within the same Sanity project. You configure which dataset to use via environment variables:
// sanity.config.ts
export default defineConfig({
projectId: 'your-project-id',
dataset: process.env.SANITY_STUDIO_DATASET || 'production',
// ... rest of config
})Then you'd set SANITY_STUDIO_DATASET=development locally and SANITY_STUDIO_DATASET=production in your production environment.
Option 2: Workspaces (Multiple Studios in One)
Workspaces let you configure multiple isolated Studio configurations within a single codebase. Each workspace can point to a different dataset:
// sanity.config.ts
export default defineConfig([
{
name: 'development',
title: 'Development',
projectId: 'your-project-id',
dataset: 'development',
basePath: '/dev',
// ... schema and plugins
},
{
name: 'production',
title: 'Production',
projectId: 'your-project-id',
dataset: 'production',
basePath: '/prod',
// ... schema and plugins
}
])With workspaces, you get a single Studio deployment with a dropdown to switch between environments. Each workspace gets its own URL path based on the basePath.
Deploying Your Studio
When you run sanity deploy, you're deploying your Studio code (the UI application) to Sanity's hosting at your-project-name.sanity.studio.
Important: sanity deploy deploys to a single hostname per project. If you want multiple Studio URLs (like dev.sanity.studio and prod.sanity.studio), you'd need to either:
- Use workspaces with different
basePathvalues (one deployment, multiple paths) - Self-host separate Studio instances on your own infrastructure
For most teams, using one Studio deployment with workspaces or environment variables to switch datasets works best. You don't typically need separate Studio deployments - just different datasets for your content.
How the Studio Knows Which Dataset
The Studio knows which dataset to use based on your sanity.config.ts configuration. When you open your Studio:
- With environment variables: It uses whatever dataset is specified in your config
- With workspaces: You see a dropdown in the Studio UI to switch between workspaces, and each workspace connects to its configured dataset
The beauty of this setup is that your schemas and Studio code can be identical across environments - only the content differs between datasets.
Show original thread32 replies
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.