Trouble publishing data on deployed Sanity studio, solved by adding production environment variables

25 replies
Last updated: Apr 15, 2021
HALP! I am having trouble publishing data on my deployed studio with Sanity. When I run the studio locally, I can change data and click publish and I see the toast immediately that it was published. My deployed studio doesn't show the toast and the publish button just stays green in limbo. I can refresh the studio and see that my changes are present in the editor, so it seems the draft is being saved but not published, because I can then reload my local development copy and it was publish right away with that drafted change.
Does anyone know why my deployed studio won't complete the publish process?
AI Update

This is a frustrating issue, but the good news is it's usually solvable! The symptoms you're describing - drafts saving but publish hanging without a toast - typically point to one of a few common deployment configuration issues.

Most Likely Cause: CORS Origins

The most common reason for this behavior is that your deployed Studio's domain hasn't been added to your project's CORS (Cross-Origin Resource Sharing) origins. When your Studio tries to publish, it needs permission to make authenticated API requests to Sanity's servers. Without proper CORS configuration, the publish mutation gets blocked by the browser.

To fix this:

  1. Go to manage.sanity.io
  2. Select your project
  3. Navigate to Settings → API → CORS Origins
  4. Click Add CORS origin
  5. Enter your deployed Studio's full URL (e.g., https://your-studio.vercel.app)
  6. Important: Check the "Allow credentials" box
  7. Save

The "Allow credentials" checkbox is crucial - without it, authenticated requests (like publishing) will fail even if the domain is whitelisted.

Other Potential Issues to Check

1. Configuration File Issues

Verify your sanity.config.js (or .ts) has the correct projectId and dataset properly defined. According to the configuration documentation, these should be set in your config file:

import { defineConfig } from 'sanity'

export default defineConfig({
  projectId: 'your-project-id',
  dataset: 'production',
  // ... rest of config
})

If you're using environment variables for these values, make sure they're prefixed with SANITY_STUDIO_ (as explained in the environment variables documentation) and are properly set in your hosting platform (Vercel, Netlify, etc.) - not just in local .env files.

2. Build vs Runtime Configuration

Since drafts are saving but not publishing, your Studio is partially connected to Sanity (it can write drafts) but something is blocking the publish mutation specifically. This often happens when:

  • The Studio was built with correct config but CORS wasn't set up for the deployed domain
  • Authentication headers are being blocked due to missing "Allow credentials" in CORS settings

3. Check Browser Console

Open your browser's developer console on the deployed Studio and try to publish. Look for:

  • CORS errors mentioning "Access-Control-Allow-Origin"
  • Network requests to *.api.sanity.io that are failing
  • Any mutation errors in the console

These will give you specific clues about what's failing.

Why It Works Locally

Your local Studio works because http://localhost:3333 (or whatever port you're using) is likely already in your CORS origins, or the browser treats localhost differently for security purposes.

Try adding the CORS origin first - this solves the issue in about 90% of cases with these exact symptoms. If that doesn't work, check the browser console for specific error messages and come back with those details for more targeted troubleshooting!

Additionally, each time that I deploy my studio, running
sanity deploy
, I am left with a series of modified files after the process completes. Is this normal?
I am left with a series of modified files after the process completes.
That’s normal. It’s the result of building the studio .
For the issue in your deployed studio, I assume there are no unusual errors in the console?
Oh goodness. There is an error in the console.
It's odd that the error is not present in my local, though.
Uncaught (in promise) Error: Configuration must contain `projectId`
    at t.initConfig (app.bundle.js?50e00c9defadd899b772:1213)
Have you tried deploying more than once?
I came across
this post from last year, but unfortunately the problem seemed to resolve itself for the person (though that’s assuming the issues in your deployed studio are tied to this error).
Have you tried deploying more than once?
I came across
this post from last year, but unfortunately the problem seemed to resolve itself for the person (though that’s assuming the issues in your deployed studio are tied to this error).
Yes I deployed once again this morning.
I will try again.
Are you configuring for multiple environments in your env files, and if so, does anything differ besides the dataset?
I have not changed anything about the environment from the start, but I will look at my commits and see if something changed inadvertently.
user A
no dice. The dataset is the same on both local and on sanity.studio : "production".
K, checking into it.
I assume you’re using your set slug on publish snippet? If so, has your deployed studio worked in the past with it?
Good question. I'm not sure that my snippet would cause an issue with the projectId, but it does work locally and has also worked deployed in the past.
That seemed like the most obvious place for me to look (since that code prevents publishing), but it does work locally.
I can both publish new Tags and I can publish edited Tags.
I find it especially karmic that a developer is having their own "it works on my machine" moment here. 😆
I find it especially karmic that a developer is having their own "it works on my machine" moment here. 😆
user A
I'm going through the code of my slug documentAction. It uses the environment variables to instantiate a sanity client. Is there an issue with using these variables in production? I am certain that I've used this code in production before, but I've had egg on my face as early as two days ago so I'm willing to be wrong again.
Circling back here,
user A
, to say that the eggs are back and this time they are scrambled.
I disabled my slug snippet and publishing is working again in the deployed version of the studio. I will have to spend some time discovering the errors of my ways here. My thoughts are that this has to do with a difference in the availability of the environment variables that I have access to on the deployed studio, so I will go back to reading the documentation around that. Once I figure it out I'll be sure to bring those changes back to my community snippet as well!

Thanks for the rubber ducky'ing.
🙏
Okay, thanks Ken. I’d be interested to hear how you solve it.
user A
I had a
.env.development
but not a
.env.production
. I found this line in the documentation:

For instance, a development configuration would be named .env.development while a production version would be .env.production
https://www.sanity.io/docs/studio-environment-variables
I might include a note on my snippet documentation about the need for production environment variables to expose the connection information that enables this snippet to pull from the database and check for other existing slugs before approving a publish.

I simply copied my a
.env.development
and named it
.env.production
and now it works!
user A
I had a
.env.development
but not a
.env.production
. I found this line in the documentation:

For instance, a development configuration would be named .env.development while a production version would be .env.production
https://www.sanity.io/docs/studio-environment-variables
I might include a note on my snippet documentation about the need for production environment variables to expose the connection information that enables this snippet to pull from the database and check for other existing slugs before approving a publish.
Final note: I'm starting to realize that y'all have made things too easy. While I have read over this part of the documentation and I did so again, specifically, when I started working on this snippet; it turns out that I only read the first sentence and then moved on because my problem was easily resolved.
This time, reading the second sentence resolved my problem...


😂
Thanks!

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?