How to set up staging and production environments in Sanity Studio?

Absolutely! Setting up staging and production environments for your Sanity Studio is definitely possible, and it's a smart approach when you're making schema and UI changes. Here's how to do it:

The Basic Approach: Multiple Datasets

The key is to use separate datasets for staging and production. Datasets are completely isolated collections of content within your Sanity project - think of them as separate databases. Your Free plan includes 2 datasets, which is perfect for this setup.

Setting Up Your Environments

1. Create a staging dataset

If you don't already have one, create a staging dataset using the Sanity CLI:

sanity dataset create staging

2. Configure environment variables

Since you're deploying to Vercel, you'll want to use environment variables to control which dataset each deployment uses. The key variable is SANITY_STUDIO_API_DATASET.

In your Studio project, you can create environment-specific files:

• .env.development (for local work)
• .env.production (for production builds)

For example, in .env.development:

SANITY_STUDIO_API_DATASET="staging"

3. Set up Vercel deployments

The recommended approach is to deploy separate Studio instances to Vercel:

• Production Studio: Deploy your main branch to Vercel with SANITY_STUDIO_API_DATASET set to production
• Staging Studio: Create a separate branch (like staging) and deploy it to Vercel with SANITY_STUDIO_API_DATASET set to staging

This way, you can test schema and UI changes in your staging Studio without affecting production.

Important note: If you're using Sanity's hosted Studio (xxx.sanity.studio), you can only host one version there. For staging, you'll need to host on Vercel or another platform. Many teams host production on Sanity's hosting and staging on Vercel, or both on Vercel.

Configure CORS Origins

Don't forget to add your Vercel deployment URLs to your CORS origins in the Sanity management dashboard (manage.sanity.io):

• Add your staging domain (e.g., https://studio-staging.vercel.app)
• Add your production domain
• For Vercel preview deployments, you might want to add a wildcard like https://*.vercel.app (though be cautious with wildcards in production)

Make sure to check "Allow credentials" if you're using authentication tokens.

Alternative: Workspaces Feature

If you only need to switch between datasets but don't need different UI/schema versions, you could use Workspaces to configure multiple isolated Studio configurations within a single deployment. Each workspace can connect to a different dataset and have its own tools and plugins. However, this won't help with testing breaking schema changes since all workspaces share the same codebase - both datasets would use the same Studio code version.

For your use case where you're actively changing the schema and UI, separate deployments (as described above) are the better approach.

Deploying Changes

When you're ready to deploy Studio changes:

• Test locally against your staging dataset
• Deploy to your staging Studio on Vercel (via git push)
• Once validated, deploy to production using sanity deploy (if using Sanity hosting) or merge to your production branch (if using Vercel)

This setup gives you a safe environment to test changes before your client sees them in production!