Understanding the difference between a locally run and deployed Sanity installation in React.

3 replies
Last updated: Mar 9, 2021
Hiya.  I'm currently on my first Sanity project, and still trying to wrap my head around it. 🙂  One thing that I don't fully understand yet is the difference between a deployed Sanity installation and a locally run installation when using it with React. In
user G
’s tutorial on YouTube she added "http://localhost:3000/ " to the Sanity API whitelist. But other than using the
@sanity/cli
NPM package and the Sanity project ID, I can't think of what it is that decides if a locally run or a deployed Sanity installation is to be used. How is this logic handled? Is this documented someplace where I can read about it?
AI Update

Great question! I remember being confused about this too when I first started with Sanity. Let me break this down for you. 🙂

The key thing to understand is that Sanity Studio and your React app are separate things, even though they can both be part of your project.

What "deployed" vs "local" actually means

When we talk about a "deployed Sanity installation" vs "local," we're usually referring to where your Sanity Studio is running:

  • Local Studio: Running on http://localhost:3333 (default Studio port) via sanity dev
  • Deployed Studio: Hosted at yourproject.sanity.studio via sanity deploy

But here's the important part: your content data always lives in Sanity's cloud (the Content Lake), whether you're running Studio locally or it's deployed. You're always connecting to the same dataset.

The CORS whitelist and localhost:3000

When you add http://localhost:3000 to your CORS origins, you're telling Sanity: "Allow authenticated requests from this domain." This is needed because your React app (running on port 3000) is making requests from a browser to Sanity's APIs.

The logic that determines which Sanity project you connect to comes from your client configuration, typically something like:

import {createClient} from '@sanity/client'

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  useCdn: true,
  apiVersion: '2024-01-01'
})

That projectId is what determines which Sanity project you're connecting to - it's the same whether you're running locally or deployed. There's no separate "local" vs "deployed" Sanity installation for your content. As the documentation notes, Project IDs are not secret - they're safe to commit to version control and will be visible in your application code.

Why add different domains to CORS?

You add different origins to CORS as you deploy to different environments:

  • http://localhost:3000 - for local React development
  • http://localhost:3333 - for local Studio (if using auth tokens)
  • https://your-production-site.com - for your deployed React app
  • https://yourproject.sanity.studio - for your deployed Studio

Each domain that needs to make authenticated requests needs to be whitelisted. You can manage these in your Sanity Management Dashboard under Settings > API > CORS Origins. Make sure to check "Allow credentials" if you're using authentication tokens with your client.

The beauty of this setup is you can develop locally while working with real production data (or a development dataset), and your deployed app uses the exact same configuration - just with a different domain in the CORS whitelist.

I am also new to Sanity, working on my first project. I will try to answer this question for you, but there may be other people more experienced than I am who can answer.
When running your local studio and making changes to your schema/etc, the only thing that is local to your machine is the code for the studio. The dataset being used is the one hosted by
sanity.io , and the studio is making requests to sanity.io for whichever dataset you have configured.
One you have finished making changes to your schema, you commit those changes and deploy them to your hosted studio on
sanity.io . If you use the studio code in your project, hosted somewhere else, it will still be making requests to the dataset on sanity.io .
Ah, I think I understand now. My React site is getting the data from Sanity's servers no matter if Sanity Studio is running on my computer or not. It's Sanity Studio that I'm running locally, and it's the schemas that I'm deploying to Sanity's servers, not the data in the database. Furthermore, I can have data in the Sanity database that aren't defined in the schemas in Sanity Studio (I've seen the error message in Sanity Studio at one time), just as I can have data fields defined in Sanity Studio (i.e. the schemas) that has no data in the database. Sanity Studio and the schemas is just a way to access, organize and edit the data in the database.
Is this just about right?
user M
I believe that is right, yes!

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.

Was this answer helpful?