Get help on Discord

Schema mismatch between local development and production deployment

22 replies
Last updated: Jun 6, 2022
I'm not sure why, but I'm seeing an old schema on a production deploys even though I see the right schema on 
sanity start
for local development... never encountered this issue before. Not sure where to start with debugging? Any help is appreciated. Thanks. 😅
AI Update

This is almost certainly a browser caching issue with your deployed Studio! The good news is it's a common problem with a straightforward fix. Here's what's happening and how to resolve it:

The Problem: Service Worker & Browser Cache

When you deploy your Studio with sanity deploy, it creates a production build that gets cached aggressively by browsers and service workers. Even though you've deployed a new schema, your browser is still serving the old cached version of the Studio.

Quick Fixes (Try These First)

  1. Hard refresh your browser on the production Studio:

    • Windows/Linux: Ctrl + Shift + R or Ctrl + F5
    • Mac: Cmd + Shift + R

  2. Clear your browser cache specifically for your *.sanity.studio domain

  3. Open in incognito/private browsing mode to test if it's cache-related (this will confirm the diagnosis)

The Permanent Solution

If hard refreshing doesn't work or the issue keeps coming back, you may need to clear the service worker:

  1. Open your production Studio URL in Chrome/Edge
  2. Open DevTools (F12)
  3. Go to the Application tab
  4. Click Service Workers in the left sidebar
  5. Click Unregister next to your Studio's service worker
  6. Refresh the page

You can also check Cache Storage in the same Application tab and manually clear it.

Why Local Works But Production Doesn't

When you run sanity start locally, you're running a development server that doesn't use aggressive caching or service workers. That's why you see the correct schema locally but not in production—it's purely a client-side caching issue, not a deployment problem.

Verify Your Deployment

To confirm your schema actually deployed correctly, you can:

  • Check the deployment logs after running sanity deploy
  • Log in to sanity.io/manage and verify your project shows the latest deployment timestamp

The schema deployment happens automatically when you run sanity deploy, so if that command succeeded, your schema is definitely updated on the server—it's just your browser holding onto the old version.

Let us know if the hard refresh fixes it! 😊

Show original thread
22 replies
Out of curiosity, are you undeploying and then redeploying in place to the same URL?
Or just doing a follow-up deploy to overwrite what's there?

Does Vercel show anything goofy in the logs that might hint at why it's not taking it up?
Doing a follow-up deploy to overwrite what's there. The logs complete successfully.
- Clearing output folder
✔ Clearing output folder (4ms)
- Building Sanity
✔ Building Sanity (13115ms)
- Building index document
✔ Building index document (26ms)
- Minifying JavaScript bundles
✔ Minifying JavaScript bundles (24863ms)
Done in 39.72s.
Can you try running 
sanity undeploy
then 
sanity deploy
to see if that helps?
Ah, I see now in a thread below you said this is on Vercel. Disregard!
Yeah. This is bizarre. I even completely destroyed the Vercel project and created a new one, but it's still showing the old schema.
The document is updated though because it's reporting unknown fields:
If the schema definition changes are recognized enough to report missing fields, what's the most noticeable difference that's left that doesn't mirror the local version? Are there console log errors while using the two different studios that differ from each other?
I wonder if deleting the 
dist
folder and running 
sanity build
before trying to deploy will unscramble whatever's happening?
Deleting and recreating the entire Vercel project should do the same, right?
But that still shows the old version.
I only see one console log message, but it happens for: 
Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
Not sure what else I could try other than completely deleting the Sanity project and starting over.
I think I might know what's happening...
I figured it out. 😅
Super curious what it was, if you don't mind sharing?
What was it 👀 ?!
I followed the Vercel documentation for deploying Sanity Studio, which included building to the 
public
directory: https://vercel.com/guides/deploying-sanity-studio-with-vercel#step-2:-preparing-for-deployment
Which meant I kept 
public
in 
.gitignore
, but not 
dist
, so my 
dist
dir was in version control by accident.
The Vercel docs didn't include setting 
public
as the output directory so it was serving the default 
dist
.
Aaaah that makes sense. I have done Next.js sites on there where using the default dev and build settings and paths almost never work....I have a totally separate build folder in my config just so I don't step on own my toes with local testing so I wound up using that separate one anyway whenever I go live.
Yeah. We should probably recommend that the Vercel docs be updated to use the default build directory.

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.

Get started for freeExplore the demo

Was this answer helpful?