Environment variables undefined in sanity.cli.ts during deployment

11 replies
Last updated: Jan 15, 2026
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

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?