Different desk structure for `sanity start` vs `sanity build`

11 replies
Last updated: May 28, 2020
Apologize for asking the same question again, but this is a bit of a roadblock for me at the moment...I'm trying to render my desk structure differently depending on whether Sanity Studio is being run via
sanity start
or has been built with
sanity build
.I've tried using environment variables, but it doesn't seem like any of the environment variables get passed through to the front end even if I prepend them with
SANITY_STUDIO_
.If anyone can help, it would be greatly appreciated.
AI Update

No worries about asking again! This is definitely a common roadblock. Let me clarify what's happening with environment variables in Sanity Studio.

The good news is that SANITY_STUDIO_ prefixed variables do work in Sanity Studio, but you need to set them up correctly using environment-specific .env files.

The Solution

Create two separate .env files in your Studio folder:

.env.development (loaded during sanity start):

SANITY_STUDIO_IS_PRODUCTION=false

.env.production (loaded during sanity build):

SANITY_STUDIO_IS_PRODUCTION=true

Then in your desk structure file, access them using process.env:

// In your desk structure file
export const structure = (S) => {
  const isProduction = process.env.SANITY_STUDIO_IS_PRODUCTION === 'true'
  
  if (isProduction) {
    // Production desk structure
    return S.list()
      .title('Content')
      .items([
        // your production items
      ])
  }
  
  // Development desk structure
  return S.list()
    .title('Content (Dev)')
    .items([
      // your dev items with extra tools, debug panels, etc.
    ])
}

Why This Works

According to the Sanity documentation on environment variables, Sanity Studio automatically loads the appropriate .env file based on the SANITY_ACTIVE_ENV variable, which defaults to:

  • 'development' when running sanity start
  • 'production' when running sanity build

The key requirements are:

  1. Prefix with SANITY_STUDIO_ - This is mandatory for variables to be passed to the frontend
  2. Use process.env - Access variables via process.env.SANITY_STUDIO_YOUR_VAR (not import.meta.env)
  3. Create separate .env files - Use .env.development and .env.production for different environments

Important Notes

  • These environment variables are exposed in your built application - they're not secret. Don't put sensitive tokens here.
  • Remember to add .env* to your .gitignore if you add any sensitive values
  • The values are embedded at build time, so if you change them, you need to rebuild

This approach gives you clean separation between your development and production desk structures without any hacky workarounds!

Show original thread
11 replies
Have you created the files .
env.development
&
.env.production
?
or how do you create the variables?
Indeed, what Hafffe said - you would need these two specific file names (not just
.env
) to have the vars get picked up at
sanity start
(
.env.development
) or `sanity build`/`sanity deploy` (
.env.production
). The prefix you’re using looks correct!
Indeed, what Hafffe said - you would need these two specific file names (not just
.env
) to have the vars get picked up at
sanity start
(
.env.development
) or `sanity build`/`sanity deploy` (
.env.production
). The prefix you’re using looks correct!
Okay, I will give that a shot.So does that mean
this bit of documentation isn't accurate?

The environment is defined by the value of the 
SANITY_ACTIVE_ENV
 environment variable. If not defined, it will default to 
development
 when running the 
sanity start
 command, while it will use 
production
 when running 
sanity build
 and 
sanity deploy
.
You're saying I'll actually need to create a
.env.production
with something like
SANITY_STUDIO_ENVIRONMENT="production"
and a
.env.development
containing
SANITY_STUDIO_ENVIRONMENT="development"
...? There isn't an automatic way to determine within code if you're in dev or prod?
Ah, no, both
SANITY_ACTIVE_ENV
and
NODE_ENV
should be available without needing those
.env.*
files. How are you checking for them? Normally you’d use something like this:
const env = process.env.SANITY_ACTIVE_ENV || process.env.NODE_ENV || 'development'
(To test, try without the latter
|| 'development'
part)
Yeah, that is exactly what I'm currently doing. It's returning
undefined
.
And I'm doing that in a desk structure implementation file, to be clear.
Hmm that’s strange indeed - just tried to reproduce. When I add this to the top of `deskStructure.js`:
const env = process.env.SANITY_ACTIVE_ENV || process.env.NODE_ENV
console.log('env:',env)
I get
env: development
logged to console in a development environment (
sanity start
).
Are you getting
undefined
for the exact same approach?
Lemme try one tweak...
Okay...Sorry about that – got caught up in some other things.Looks like
NODE_ENV
does work. It's
SANITY_ACTIVE_ENV
that is
undefined
. So that gives me something usable. 👍

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?