Sanity Studio loading .env.production instead of .env.development locally

21 replies
Last updated: Jan 28, 2026
Hey, had a question regarding environment variables. I have a
.env.development
&
.env.production
in my root directory, and in both I have a pair of variables but with different values depending on if I’m working locally (which should be using
.env.development
), or if I run
sanity deploy
which should then be using
.env.production
. However, after adding the
.env.production
my local studio (which is ran using
sanity start
) keeps loading the variables from this dot env file rather than from
.env.development
. If I delete the production dot env the values from
.env.development
are loaded correctly. Has anyone run into this issue before? Thanks!
Edit: I also have a
sanity.json
in which I define the different datasets (one for production, one for staging, one for develop, as well as one that I use locally only). Not sure if that makes a difference.
AI Update

Based on the documentation, I can see what's happening here. The issue is that Sanity Studio's environment variable loading behavior depends on the SANITY_ACTIVE_ENV variable, which defaults to development for sanity start and production for sanity build and sanity deploy.

However, there's a known quirk: when both .env.development and .env.production files exist, the loading order can sometimes cause .env.production to take precedence or override .env.development values, depending on how your build tooling processes these files.

Here are a few solutions:

Option 1: Use SANITY_ACTIVE_ENV explicitly

When running locally, explicitly set the environment:

SANITY_ACTIVE_ENV=development sanity start

This ensures the correct environment is active.

Option 2: Use a single .env file with conditional logic

Instead of separate .env.development and .env.production files, use a single .env file and handle environment switching in your sanity.config.js:

export default defineConfig({
  projectId: process.env.SANITY_STUDIO_API_PROJECT_ID,
  dataset: process.env.SANITY_ACTIVE_ENV === 'production' 
    ? 'production-dataset' 
    : 'development-dataset',
  // other config
})

Option 3: Use .env.local for local overrides

Create a .env.local file for your local development variables. This file typically has the highest priority in most build systems and won't be used during deployment. Make sure to add it to your .gitignore.

About your sanity.json mention: If you're using sanity.json, you might be on an older version of Sanity Studio (v2). The environment variable behavior was more predictable in Studio v3+, so consider upgrading if you're still on v2.

Quick workaround: For now, you could temporarily rename .env.production to something like .env.production.backup while developing locally, then rename it back before deploying. Not elegant, but it'll unblock you.

The root cause is likely related to how your bundler (Vite in Studio v3, or webpack in Studio v2) processes multiple .env files. The SANITY_ACTIVE_ENV variable should control this, but explicit setting (Option 1) is the most reliable approach.

Show original thread
21 replies

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?