Summary:
Issue: Turbopack’s static analysis is not detecting direct process.env.MY_CUSTOM_VAR_1 and process.env.MY_CUSTOM_VAR_2 references in server-side code (API routes and server functions), causing these variables to be excluded from the TURBO_PLATFORM_ENV whitelist and unavailable at runtime.
Environment:
Next.js: 16.0.3
Deployment: Vercel Production
Evidence: The TURBO_PLATFORM_ENV whitelist remains stuck with only 6 variables despite multiple fresh builds:
“TURBO_PLATFORM_ENV”:“VAR_A,VAR_B,VAR_C,VAR_D,VAR_E,VAR_F”
Code references: All variables are referenced in server-side API routes and utility functions using direct syntax: process.env.MY_CUSTOM_VAR_1 (no dynamic construction)
What we’ve tried:
Clearing build cache (manually and via VERCEL_FORCE_NO_BUILD_CACHE=1)
Multiple fresh deployments
Removing variables from next.config.ts
Direct references only (no bracket notation or dynamic construction)
Verifying variables are set correctly in Vercel dashboard
Pattern observation: Some environment variables (e.g., VAR_A) are correctly detected and whitelisted, but others (e.g., MY_CUSTOM_VAR_1) are not, despite both being:
Set in Vercel environment variables
Directly referenced in server-side code
Used in the same files
This suggests a potential bug in Turbopack’s pattern matching or variable name handling (possibly related to name length, prefix patterns, or underscore count).
Anybody understand why Turbopack’s static analysis fails to detect these specific variable references ?
This looks like a Turborepo issue and not a Turbopack one? TURBO_PLATFORM_ENV is a Turborepo feature. The naming is really confusing (our fault!), but Turbopack and Turborepo are entirely separate products.
Turbopack does perform static analysis of process.env and tries to replace those references at build time, but I don’t think Turborepo has anything like this. It is possible that your code is written in a way that evades Turbopack’s static analysis, but that wouldn’t have any impact on TURBO_PLATFORM_ENV, and I don’t think that’s the issue here.
causing these variables to be excluded from the TURBO_PLATFORM_ENV whitelist and unavailable at runtime
I’m not very familiar with Turborepo, but reading through Using environment variables | Turborepo gives me the impression that TURBO_PLATFORM_ENV is just used for generating warnings if you forgot to declare an environment variable in your turbo.json, meaning that you still need to explicitly need to declare these environment variables there.
@bgw is one right track. Have you accounted for the variables in your env key of turbo.json? If you haven’t they will be omitted from the task. More information in our docs: Using environment variables | Turborepo
As a matter of fact, I did try a brand new deployment on Netlify and it worked right the way. So I am really suspecting an issue with the way Vercel is handling those environment variables.
After many hours of digging I found the culprit: there were 2 projects with the same name except the post fix : “myproject-gilt.vercel.app" and “myproject-tbma.vercel.app". The deployments were happening automatically on the 2.
The first one was having the good set of env variables and the second just a subset. When I was doing my manual testing I was using the wrong one (aka “tbma”) and all the different things we tried were of course not working.
So I finally understood that and now everything is working properly.
Now, that DOES NOT explain why the “tbma” project was there. I never ever created a second project.
I AM SUSPECTING it was automatically created when adding the Neon database support to the first project and I would encourage the Vercel folks to look at this issue as this is a terrible one that led me loose a full day of work.
