Prevent dataset mismatch: UI deployment doesn't reflect sanity.json changes

I feel your pain – this is a classic mistake that's bitten many developers! The good news is that Sanity does support patterns that can prevent this exact scenario, though they might not be immediately obvious.

Multiple Studio Deployments (Already Possible!)

Your second suggestion is actually already supported. You can deploy multiple Studio instances to different subdomains on Sanity's hosting, each permanently configured for a specific dataset. This is the recommended approach and doesn't cost extra.

Here's how it works: When you run sanity deploy, you're prompted to choose a hostname. You can deploy multiple times with different configurations:

# In your sanity.config.ts, use environment variables
export default defineConfig({
  projectId: 'your-project-id',
  dataset: process.env.SANITY_STUDIO_DATASET || 'production',
  // ... rest of config
})

Then deploy separate instances:

# Deploy production Studio
SANITY_STUDIO_DATASET=production sanity deploy
# When prompted, enter hostname: acme-production

# Deploy development Studio  
SANITY_STUDIO_DATASET=development sanity deploy
# When prompted, enter hostname: acme-development

This gives you acme-production.sanity.studio and acme-development.sanity.studio as permanent, separate URLs. Each deployment is locked to its dataset configuration – no chance of forgetting to redeploy because you never change the production Studio's config. This approach is covered in the multi-environment deployments guide and the setting up your environments course.

Dataset Indicator in the UI

For a visual safety net, you can add a banner showing which dataset is active. Using Studio's configuration API with defineConfig, you can customize the navbar:

import { defineConfig } from 'sanity'

const datasetBanner = () => {
  const dataset = process.env.SANITY_STUDIO_DATASET || 'production'
  return (
    <div style={{
      background: dataset === 'production' ? '#f03e2f' : '#f59e0b',
      color: 'white',
      padding: '8px',
      textAlign: 'center',
      fontWeight: 'bold',
      fontSize: '14px'
    }}>
      ⚠️ {dataset.toUpperCase()} DATASET
    </div>
  )
}

export default defineConfig({
  // ... your config
  studio: {
    components: {
      navbar: (props) => (
        <>
          {datasetBanner()}
          {props.renderDefault(props)}
        </>
      )
    }
  }
})

There are also community plugins that add environment badges, though you'll want to verify Studio v3 compatibility.

The Real Solution: Never Change Production Config

The best practice combines both approaches:

1. Deploy separate Studios for each environment – your production Studio at acme-production.sanity.studio is permanently configured for production, eliminating the "forgot to redeploy" problem entirely
2. Use environment-specific .env files locally (.env.development, .env.production) so developers automatically work with the right dataset when running sanity dev or sanity build
3. Add visual indicators as an extra safety layer

This way, there's no deployment step that could be forgotten. Your team always knows which URL to use, and the mistake you experienced becomes architecturally impossible.

What About Workspaces?

You might also consider Workspaces, which let you configure multiple datasets within a single Studio deployment with a built-in switcher. However, this doesn't solve your specific problem – you'd still need to remember to deploy after changing configuration. Workspaces are better suited for multi-tenant scenarios or when you want editors to easily switch between datasets, not for preventing deployment mistakes.

The separate deployment approach is really the gold standard here – it turns your configuration mistake into an impossibility rather than relying on memory or visual cues.