Env Development & Production Environment Variables

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.

Update: When prefixing it’s now using the correct variables in

.env.development

. This is pretty tedious and error-prone if I have to prefix the ENV variable value every time I run

sanity start

locally. Any idea why this is the case and how I can fix it so that it defaults to the development environment when running

sanity start

?
It was my understanding that this should be the case already by default..

Yes, you can use

SANITY_ACTIVE_ENV

in that way , but expected behaviour is to work based on your original code (i.e., without that prefix). The team is looking into it. CC:

Thanks. Again not sure if it makes a difference but we’re also using the experimental Spaces feature in

sanity.json

. But my hunch is that shouldn’t affect anything in this regard since

sanity start

should still be using the development ACTIVE_ENV by default anyways.

Thanks. Again not sure if it makes a difference but we’re also using the experimental Spaces feature in

sanity.json

. But my hunch is that shouldn’t affect anything in this regard since

sanity start

should still be using the development ACTIVE_ENV by default anyways.

It’s also interesting that even via the prefix route (in which case the right variable values are getting loaded), I still get

undefined

when I print out the value of

SANITY_ACTIVE_ENV

.

It’s also interesting that even via the prefix route (in which case the right variable values are getting loaded), I still get

undefined

when I print out the value of

SANITY_ACTIVE_ENV

.

I don’t know that you can access

SANITY_ACTIVE_ENV

from your code. You could try

process.env.NODE_ENV

(though I’m not sure that helps as I don’t know that they’re equivalent).

Oh gotcha. I didn’t need access to the value, just figured it was interesting and might help you guys as you look into this 😅

Thanks!! Is there an ETA for the fix, and would this mean needing to update our Sanity modules to get it?

Will let you know.

the fix is now published: https://github.com/sanity-io/sanity/releases/tag/v2.10.5 . Thanks again for reporting! 🙂

Thanks a lot! Will upgrade our repo and report back if there are any issues still 🙂

Thanks for remembering to loop back

Hey & ! Thanks again for the quick fixes. However, unfortunately we seem to be having the opposite issue now. I deployed our studio using

sanity deploy

(hosted with Sanity), and even got this message as part of the deploy process:
However, once I went into the production studio to confirm everything’s working, it is now using the development keys instead of the ones in

.env.production

that was present in my directory when I ran

sanity deploy

. From my understanding from the docs , the environment should be automatically defined as

production

when running `sanity deploy`; any idea why I’m now seeing development keys being used instead of production?
And for added clarity my local environment when developing was working correctly now (

.env.development

keys being used instead of

.env.production

), so the original issue I had was fixed 😅.
Thanks.

Hey , the original & follow-up issues have unfortunately been blockers on our side for over 3 weeks at this point. Have you been able to reproduce the issue on your side & are there any updates to share on a solution since the last time you pinged me on the 4th ? Happy to provide any extra information you may need about our Studio setup or anything else. Thanks.

Hi - acknowledging that 3 weeks is a long time to wait for a blocker like this to be removed. Apologies for the delay here. I'll do my best to get you an update by end of day tomorrow. If you wouldn't mind sharing your

sanity.json

(in DM if you prefer) or even access to your studio repository, that would be helpful in confirming any potential fix.

Sure thing, I’ll DM you our

sanity.json

.

Hi , pinging you again about any updates on this since the last time we chatted. I DM’d you our

sanity.json

that day, and if needed I can get you access to our repo for additional visibility (feel free to DM me which GitHub account we should be giving access to).
This is still a blocker on our end after almost 4 weeks so would appreciate if you could escalate this to near the front of the queue.. thanks!

Pinging the channel again for help regarding this issue as I haven’t heard back from .. it’s now been over a month since the original issue was brought up, would still appreciate any help or updates around this.. Thanks.

Hi , sorry about not getting back to you earlier. Unfortunately, your follow-up issue coincided with the release of the new Manage interface and the new roles system last week. The release itself and work coming out of it (e.g. bug fixes) meant that your issue is taking longer to pick up than we'd like. I'll follow up today with either an update or a potential workaround. Thank you for your patience these last few weeks - much appreciated.

could you try adding the snippet below to your

sanity.json

file, replacing

<projectId>

with the actual project ID? I'll share the full example in DM.