Difference between deployed and local Sanity: How does it decide which to use?
@sanity/cliNPM 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?
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) viasanity dev - Deployed Studio: Hosted at
yourproject.sanity.studioviasanity 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 developmenthttp://localhost:3333- for local Studio (if using auth tokens)https://your-production-site.com- for your deployed React apphttps://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.
Show original thread3 replies
Was this answer helpful?
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.
