Issue with environment variables in a NextJS and Sanity app, seeking help and suggestions.

18 replies
Last updated: Nov 22, 2021
Hello 🙂I have reasons to believe that my Sanity & NextJS app have a problem using environment variables
😕
AI Update

I can help you troubleshoot environment variable issues with your Sanity & Next.js setup! This is a common pain point because the two systems use different prefixes.

The Two-Prefix System

When you have Sanity Studio embedded in a Next.js app, you need to understand that two different prefix systems are at play:

For Next.js Variables

Variables that need to be accessible in the browser must use the NEXT_PUBLIC_ prefix:

NEXT_PUBLIC_SANITY_PROJECT_ID=your-project-id
NEXT_PUBLIC_SANITY_DATASET=production

For Sanity Studio Variables

If you're running Sanity Studio (either standalone or embedded), variables need the SANITY_STUDIO_ prefix:

SANITY_STUDIO_API_PROJECT_ID=your-project-id
SANITY_STUDIO_API_DATASET=production

Common Problems & Solutions

Problem 1: Embedded Studio in Next.js When you embed Sanity Studio in Next.js (like at /studio route), you often need both prefixes for the same values:

# For Next.js pages/components
NEXT_PUBLIC_SANITY_PROJECT_ID=abc123
NEXT_PUBLIC_SANITY_DATASET=production

# For embedded Studio
SANITY_STUDIO_API_PROJECT_ID=abc123
SANITY_STUDIO_API_DATASET=production

Problem 2: Server-side vs Client-side Remember that NEXT_PUBLIC_ variables are exposed to the browser. For server-only operations (like using tokens), don't use the NEXT_PUBLIC_ prefix:

# Server-side only (never exposed to browser)
SANITY_API_TOKEN=your-secret-token

# Client-side accessible
NEXT_PUBLIC_SANITY_PROJECT_ID=abc123

Problem 3: Not Restarting Dev Server After changing .env files, you must restart your Next.js dev server. The variables are only loaded at startup.

Problem 4: Wrong .env File Make sure you're using the right file:

  • .env.local - loaded in all environments (gitignored by default)
  • .env.development - only in development
  • .env.production - only in production builds

Quick Debugging Checklist

  1. Check your variable names have the correct prefix (NEXT_PUBLIC_ or SANITY_STUDIO_)
  2. Restart your dev server after any .env changes
  3. Verify the values are loading: console.log(process.env.NEXT_PUBLIC_SANITY_PROJECT_ID)
  4. Make sure your .env.local file is in the root of your Next.js project
  5. Check that sensitive .env.local files are in .gitignore

Typical Setup for Next.js + Sanity

Here's what a standard .env.local file looks like for an embedded Studio:

# For Next.js client-side
NEXT_PUBLIC_SANITY_PROJECT_ID=abc123
NEXT_PUBLIC_SANITY_DATASET=production

# For embedded Sanity Studio
SANITY_STUDIO_API_PROJECT_ID=abc123
SANITY_STUDIO_API_DATASET=production

# For server-side API routes (no NEXT_PUBLIC!)
SANITY_API_READ_TOKEN=your-token-here

The key thing to remember: project IDs and dataset names aren't secret and will be exposed in your built application anyway, so using NEXT_PUBLIC_ for them is fine. But keep API tokens server-side only without the NEXT_PUBLIC_ prefix!

they yield an
undefined
value
according to the following, it might have something to do with
dotenv
which is featured on Sanity https://github.com/vercel/next.js/discussions/12754#discussioncomment-13033
my question is: is it ok to remove the package from Studio?
hmm actually, I don’t think that will be possible, am I right?
any other ideas as to how to fix this issue please?
this is the code I’m working on https://github.com/eugelogic/gothenburg
Hi Eugene - perhaps you've already been down this road, but I banged my head on the .env for a while until I found in the docs that for the studio you need to prefix them with
SANITY_STUDIO
. Is that any help? https://www.sanity.io/docs/studio-environment-variables#f5e9e3158896
Hi Joseph, thanks for getting back to me.I did not know about that, good to know.
Unfortunately my issue lives in the NextJS part of my project and I need to prefix the variables with
NEXT_PUBLIC_
This is really puzzling, I’ve spent hours and read lots but whatever I find is related to either NextJS or Sanity, no the two together, I can’t believe I’m the only one facing such issue
🤔
or maybe I’m missing something obvious, it might worth mentioning I use Lerna and Yarn Workspaces 🙄
Hi - I don't have particular experience with Next and I don't do any monorepo stuff regularly (having 2+ repos has worked for me, but I do most projects solo). But maybe it's something to do with how your build process is configured with Lerna? Have you tried making a copy of your Next repo and running a build on it locally to see if that build will incorporate your environment variables correctly? That way you could rule out any weird syntax mistake you might be missing on the Next side of things?
Could you share the bit of code where you use the env variables that turned out to be undefined & also where you put them? .env.local?
hi
user U
I did try to run
build
but it would flag that the env variable is
undefined
also tried to hardcode the actual value of the env variable and it did work so it’s something to do with
process.env
I guess
hi
user G
the code lives at https://github.com/eugelogic/gothenburg/blob/main/web/lib/config.js and my env variables live in a
.env.local
file in the root of the repo which of course you can’t see online because I’m not committing it GitHub
Just to be clear, the .env.local is in the
web
directory and not the root directory, is that correct? Because I think Next wouldn’t see it otherwise
no it’s in the root of the project, not inside the
web
folderI did read somewhere Next would be able to see it regardless
+ I did move it inside to see if that was the issue, re-started the server but it didn’t help, lemme try again
lol -
user G
it works 😅I have no idea why it didn’t when I tried the other day but it does now
thanks for making trying again
👍
Nice! Glad you got it figured out!
much appreciated 🙏

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?