Environment variables undefined in sanity.cli.ts during deployment

11 replies
Last updated: Jan 4, 2023
I want to report a bug.
If you want to use the process.env
SANITY_STUDIO_API_PROJECT_ID
and
SANITY_STUDIO_API_DATASET
it will not work inside the
*<http://sanity.cl|sanity.cl>*i.ts
file if you try to deploy the sanity studio it will return the env variables as
undefined
to solve this you have to add a prefix with
VITE_
😄 This only happens in production and deployment though.
So the current fix for the guys out there having the same issues instead of doing this:


import { defineCliConfig } from 'sanity/cli'

const projectId = process.env.SANITY_STUDIO_API_PROJECT_ID
const dataset = process.env.SANITY_STUDIO_API_DATASET

export default defineCliConfig({ api: { projectId, dataset } })
Do this:

import * as dotenv from 'dotenv'

dotenv.config()

import { defineCliConfig } from 'sanity/cli'

const projectId = process.env.SANITY_STUDIO_API_PROJECT_ID
const dataset = process.env.SANITY_STUDIO_API_DATASET

export default defineCliConfig({ api: { projectId, dataset } })
AI Update

Thanks for reporting this! I need to clarify something important about how environment variables work in Sanity Studio, because there's actually a misunderstanding here.

According to the official Sanity documentation on environment variables, environment variables prefixed with SANITY_STUDIO_ are automatically picked up by the Sanity CLI tool, development server and bundler. The docs explicitly state these variables are "available as process.env.SANITY_STUDIO_VARIABLE_NAME" in all CLI contexts.

This means your environment variables should work in sanity.cli.ts without needing dotenv.config(). If they're returning undefined during deployment, it's not a bug—it indicates your environment isn't properly configured.

Here's what's likely happening:

Sanity automatically loads .env files based on the active mode:

  • .env.development is loaded during sanity start
  • .env.production is loaded during sanity build and sanity deploy
  • .env (no suffix) is loaded in all cases

The solution:

  1. Create a .env.production file in your project root:
SANITY_STUDIO_API_PROJECT_ID=your-project-id
SANITY_STUDIO_API_DATASET=your-dataset
  1. Or use .env (without a suffix) if you want the same values in all environments

  2. Your sanity.cli.ts should work as-is:

import { defineCliConfig } from 'sanity/cli'

const projectId = process.env.SANITY_STUDIO_API_PROJECT_ID
const dataset = process.env.SANITY_STUDIO_API_DATASET

export default defineCliConfig({ api: { projectId, dataset } })

Why your dotenv.config() workaround works:

You're manually loading environment variables before Sanity's automatic loading happens. This works, but it's treating the symptom rather than the root cause. The real issue is that your .env.production file is either missing or not in the right location.

Important note about the VITE_ prefix:

While VITE_ prefixed variables work (since Studio v3 uses Vite), the Sanity docs recommend using process.env over import.meta.env and sticking with the SANITY_STUDIO_ prefix. This keeps your code consistent across different contexts and makes future migrations easier.

If you're deploying via CI/CD:

Make sure your deployment environment either includes the .env.production file or sets the environment variables directly in your CI/CD configuration (like GitHub Actions secrets, Vercel environment variables, etc.).

The behavior you're experiencing isn't a bug—it's how environment variable loading is designed to work with different modes. The SANITY_STUDIO_ prefix should work everywhere the CLI runs, as long as your .env files are properly set up for each environment.

Show original thread
11 replies
That config file is for the CLI, which does not run in the browser. If you're using environment variables there you will need to use
dotenv
. I don't believe this is a bug, just a side effect of how env vars work.
Hey hey 🙂 Did you follow these steps ?
user Q
Thank you so much for this fix, I was halfway there with the help from
user M
but i hadn't converted from "import.meta.env" to "process.env"

user J
the steps on that page work fine for local deployment but seem to break trying to deploy to sanity or deploy the graphql schema
I will investigate further with
user M
This is what I had to do to get it to work both locally and when deploying. I'm sure there's a much better way to do this but it's a bandaid fix for now.
Hi
user E
I am going through my old threads and was wondering if you still have this issue?I can see you are mixing imports still

if (!projectId || !dataset || !googleMapsApiKey) {
  dotenv.config()
  projectId = process.env?.SANITY_STUDIO_PROJECT_ID
  dataset = process.env?.SANITY_STUDIO_DATASET
  googleMapsApiKey = process.env?.SANITY_STUDIO_GOOGLE_MAPS_API_KEY
}
You do it the right way in the beginning and then change back to process.env.
Running locally require import.meta.env but when trying to run sanity deploy it returns null, but process.env seems to work. So I check if import.meta.env returned anything and if not I use the dotenv method
Well, tbh, i dont even understand what you’re issue is now. I think you talked to
user M
inanother thread.Can you please share what issue you’re experiencing?
I'll try to explain what's happening as best I can, although I'm not incredibly well versed in env variables and how these things work under the hood so please forgive me if I dont explain well or am missing something.
This is my sanity.config.js file. First try to load the env variables as instructed the sanity v3 documentation. This works when I run
sanity dev
and
sanity deploy
. This however does not seem to work when I try to run
sanity graphql deploy
which fails with this error `Error: Configuration must contain `projectId`` . To combat this I check to see if the values for projectId, dataset, and googleMapsApiKey exist, and if not i use the dotenv method to retrieve these which was recommended by
user M
.
This seems to fix the issue. The reason I dont just use the dotenv method only is because it seems to ONLY work when trying to run
sanity graphql deploy
. So first I try to get the env variables with the recommended method, then use dotenv if that fails
Thank you for the explanation 🙂 Are you able to deploy with the workaround now?
Yes the workaround seems to be functioning

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?