Multi-client setup for multi-tenancy with separate studios in Sanity

Great question! Let me clarify the different approaches for multi-tenancy in Sanity, since there's an important distinction between workspaces and separate projects.

Understanding Your Options

When you mention "multi clients," there are actually two architectural approaches:

1. Single Project with Multiple Datasets + Workspaces

This is what the tutorial you saw likely covered. You configure workspaces in your sanity.config.ts like this:

import {defineConfig} from 'sanity'

export default defineConfig([
  {
    projectId: 'abc123',
    dataset: 'client-a',
    name: 'client-a-workspace',
    basePath: '/client-a',
    title: 'Client A',
    // ... schema and plugins
  },
  {
    projectId: 'abc123',
    dataset: 'client-b', 
    name: 'client-b-workspace',
    basePath: '/client-b',
    title: 'Client B',
    // ... schema and plugins
  },
])

The problem: By default, all users can see all workspaces in the workspace switcher dropdown. To truly isolate clients from seeing each other's workspaces, you need Custom Roles (Enterprise plan only) to restrict dataset access. Even then, users will still see the same Studio URL and potentially the workspace switcher.

2. Separate Sanity Projects (True Isolation)

For complete isolation where clients can't see each other's Studios at all, you need separate Sanity projects - not just separate datasets. This means:

• Each client gets their own project ID
• Each client accesses a completely different Studio URL (either self-hosted or separate Sanity-hosted deployments)
• Each client has their own separate user management
• Complete billing separation if needed

This is the approach if you want true "multi clients" where each client has zero visibility into other clients' existence.

Recommended Approach

If you need complete Studio isolation (which it sounds like you do), I'd recommend:

1. Create separate Sanity projects for each client - you can manage these from your organization dashboard

2. Deploy separate Studio instances for each project - either:

   • Self-host multiple Studios (each pointing to different project IDs)
   • Use Sanity's hosted Studio with different URLs per project

3. Use a single codebase with environment variables to configure which project each deployment connects to:

// sanity.config.ts
import {defineConfig} from 'sanity'

export default defineConfig({
  projectId: process.env.SANITY_STUDIO_PROJECT_ID,
  dataset: process.env.SANITY_STUDIO_DATASET || 'production',
  // ... rest of config
})

The Workspace + Custom Roles Approach

If you're on an Enterprise plan, you can use workspaces with Custom Roles and Content Resources to restrict access at the dataset level. However, this still shares the same Studio deployment, so users might see workspace names or the workspace switcher even if they can't access the content. You'd need to:

• Set datasets to private (not public)
• Create custom roles with dataset-specific permissions using GROQ filters
• Potentially customize the Studio UI to hide inaccessible workspaces

Summary

For true multi-tenancy where clients shouldn't see each other's Studios at all, separate projects with separate Studio deployments is the clearest path. Workspaces are great for internal team separation (dev/staging/prod, different departments, etc.) but not ideal for completely isolated client experiences without Enterprise features and additional customization.