.Env.Local File Configuration not working with Next.js Application

13 replies
Last updated: Jul 9, 2021
Hello Sanity, My .env.local file contains my project id and dataset name. I'm accessing them in my sanity configuration. However my NextJs application complains that I have to specify my projectId. If I hardcode the id to the sanity configuration, it works. What is actually going wrong here?
AI Update

This is a common issue when setting up Sanity with Next.js! The problem is that Next.js and Sanity Studio have different prefixing requirements for environment variables.

Here's what's happening:

In Next.js applications, environment variables need to be prefixed with NEXT_PUBLIC_ to be exposed to the browser/client-side code. When you're configuring your Sanity client in a Next.js app, you need:

NEXT_PUBLIC_SANITY_PROJECT_ID=your-project-id
NEXT_PUBLIC_SANITY_DATASET=production

Then access them like this:

// sanity.config.js or your client configuration
export default defineConfig({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID,
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET,
  // other configuration
})

If you're configuring Sanity Studio itself (not just the client in Next.js), the variables need the SANITY_STUDIO_ prefix instead:

SANITY_STUDIO_API_PROJECT_ID=your-project-id
SANITY_STUDIO_API_DATASET=production

Common mistakes:

  1. Using SANITY_STUDIO_ prefix in a Next.js app (won't work - Next.js doesn't recognize this prefix)
  2. Forgetting the NEXT_PUBLIC_ prefix (variables won't be available in browser code)
  3. Not restarting the dev server after adding/changing .env.local (Next.js only reads these on startup)

Solution: Make sure you're using NEXT_PUBLIC_ prefix in your .env.local file and restart your Next.js dev server. According to the Sanity documentation on environment variables, project IDs and dataset names are not secret and will be exposed in your built application anyway, so using NEXT_PUBLIC_ is safe here.

If you need server-side only variables (like API tokens), you can use unprefixed variables in API routes or server components, but for the Sanity client configuration that runs in the browser, you need the NEXT_PUBLIC_ prefix.

A next issue perhaps? Have you tried prefixing it with NEXT_PUBLIC_?
Eg it might be available in getStaticProps but not getInitialProps which is client side.
Aren't Project ID and dataset name secret?
I'm confused about the way NEXT_PUBLIC prefix works actually. If it exposes the variables to the browser environment, does that mean someone can steal it and tamper my data?
You tell me.
For our public datasets they are not secret as the data is public anyways. For our private datasets you need a login so no issue there either.

For your use case it might be they are? If so, you wont be able to use it on the frontend. If you restrict yourself to getStaticProps and similar it should still work.
Well they'll need to be logged in to EDIT or ADD data, but they'll have read access to all of your data if it's a public dataset.
Overall I see little reason to keep it secret, the project id will be leaked the moment you introduce any assets such as images.
Project IDs and dataset names shouldn't be considered secret - if you want your data to be private, you should be using a private dataset. In that case, you want to use a read token and do data fetching on the server side only (be sure to not prefix the token variable with
NEXT_PUBLIC
).
user A
user Z
Thank you for help
user T
There's a mistake in what I told you that day. Project ID and dataset shouldn't be secret. Please read this thread for more information
ll

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?