I am having a critical issue where my production deployment is being injected with an incorrect environment variable value. My frontend code is reading process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY, but it is receiving the value of a completely different secret variable. I have already redeployed without cache and confirmed the key is not hardcoded in my source code. This appears to be a platform bug.
Hi @mychapterpay, welcome to the Vercel Community!
I’m sorry that you are facing this issue. Can you confirm if you’ve set the environment variable correctly for the Vercel environment? For example, if you are accessing the production deployment, the variable must also be set in production.
For testing purposes, can you try adding a dummy public variable and accessing it on the frontend to see if that works?
Hi @anshumanb, thank you for the suggestion. I have completed the test, and it has revealed the core problem.
The Test Failed:
The NEXT_PUBLIC_DUMMY_TEST_VARIABLE was undefined.
The NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY is still showing the incorrect sk_live_ value.
I inspected the compiled JavaScript file from the production build, and it shows that the secret key (sk_live_…) is being hardcoded directly into the JavaScript file during the build process. This is not a runtime issue; it’s a build-time injection bug.
Please see this screenshot of the compiled JS file showing the hardcoded secret key:
This proves the Vercel build environment is incorrectly substituting the wrong variable value at build time. Please escalate this issue.
Hi @mychapterpay, thanks for digging deeper. I’ll definitely escalate this but I’d need your help in recreating the issue. Can you please share your public repo or a minimal reproducible example. That will let us all work together from the same code to figure out what’s going wrong.
Hi @anshumanb,
Thank you for escalating this. I have completed the minimal reproducible example:
Public GitHub Repo: GitHub - ThomasHoppel/vercel-bug-repo
Vercel Deployment: https://vercel-bug-repo.vercel.app
I found that the reproduction case works correctly - both environment variables show their proper values.
I believe this proves that:
- My code is correct
- Vercel’s environment variable system works fine for new projects
- My original project has a specific data corruption that is persisting despite cache clears and variable re-creation
The bug appears to be project-specific data corruption in my main project’s environment variable storage. Can your team investigate what is corrupted in my original project and fix it?
Thanks
Thanks for confirming this. Can you confirm you are accessing the variable in your production application the exact same way you are in the reproducible code? The reproducible repo you shared is not a Next.js project. Can you try to get it as close to your setup so we can debug it together?
I’ve updated the test repo to Next.js. As expected, it is still working correctly . This confirms the build error is a bug isolated to our main project. Can you please investigate the environment for mychapterpay.com?
Hi @anshumanb,
Just following up on this. Any luck investigating the project specific build bug on mychapterpay?
Hi @mychapterpay, sorry for the delayed response. But, I wasn’t able to reproduce this issue on any of my projects. I tried to clone and deploy your repo: https://vercel-bug-repo-xi.vercel.app/ and it works fine for me.
If you were able to create a working project then I’d recommend sticking with it for your use case and abandon the project where you see this bug as it could be a one-off scenario.
I’d be happy to take a closer look if we’re able to reproduce it.
Hi @anshumanb,
Following up on this. I took your advice and abandoned the original mychapterpay project, which did solve the initial Stripe environment variable bug.
I moved the exact same codebase to a new project, mychapterpay-2. This worked for a short time, but then a new issue appeared: pushed updates were not being deployed, even though the Vercel logs said “success.”
To fix this, I created a third project, mychapterpay-3. Now, on this brand new project, I have a critical authentication bug that only happens on Vercel . The application works perfectly locally, but on the Vercel deployment, a user is instantly logged out the moment they navigate to a new page after logging in.
At this point, I have rebuilt my project three times to fix three separate, critical platform-level bugs. I am losing confidence in the platform and am now strongly considering moving our application to a different provider.
Before I do, can you please have a senior engineer investigate why a standard, working Next.js application is failing on your platform? The project is mychapterpay-3.
Thank you.
Hi @mychapterpay, I’m sorry to hear that you faced the issues again. I’d be happy to help you with this but without a reproducible project I can’t suggest solutions or create an incident. I need your help in recreating the issue. If you can create a small fresh code base and recreate the issues you are sharing above then I can take that and help you out.
Hi @anshumanb,
I need to be very clear: Your request to “create a small fresh code base” is impossible, because it misunderstands the fundamental nature of the bug.
We have already done that experiment. We already have a working project: mychapterpay-3 works perfectly in our local Docker environment.
Let me summarize the facts for the incident report you need to create:
Fact #1: The Code is Correct. The exact same codebase from the exact same commit works 100% correctly when run locally. The login and authentication flow is perfect.
Fact #2: The Vercel Platform is Failing. When that same, correct codebase is deployed to Vercel (Project: mychapterpay-3), the authentication fails with a 401 Unauthorized error on every client-side page navigation.
This is the definition of a platform-specific bug. The Vercel runtime environment is behaving differently than a standard Node.js environment.
The issue is 100% reproducible. The “reproducible project” is mychapterpay-3. Any engineer on your team can be granted access, deploy it, and see the bug happen instantly.
I have spent weeks proving that this is not a code issue. I have now proven it is a platform issue. I cannot debug Vercel’s internal environment for you.
Please escalate this ticket immediately to a senior engineer or the platform team. They need to investigate the runtime configuration and logs for the mychapterpay-3 project to determine why the Authorization header is being dropped during client-side transitions.
This is a critical, launch-blocking issue, and this is our final attempt to resolve it before we migrate to another provider.
Thank you.
I appreciate you taking the time to write the facts. I’d like to highlight:
The “reproducible project” is mychapterpay-3. Any engineer on your team can be granted access, deploy it, and see the bug happen instantly.
This GitHub - ThomasHoppel/vercel-bug-repo repo doesn’t contain any auth logic you mention in your latest reply. We ask for a publicly reproducible code so everyone can pitch in to help. We don’t usually take your codebase and use it to debug because it has has many dependencies such as databases or 3rd party integrations. That’s why a minimal reproducible example is helpful.
In the meantime, I’ll try to reach out to our team to see what we can do.
Hi @anshumanb,
Thank you for agreeing to reach out to your team. To clarify, the vercel-bug-repo was for a previous, unrelated issue. The current, critical authentication bug is in our main private application.
I understand that a minimal example is usually ideal, but in this specific case, the bug only appears when our full application interacts with the Vercel production environment. It is a platform interaction bug, which is impossible to reproduce in a minimal example.
To make it as easy as possible for your team to investigate, here is everything they need:
Project Name on Vercel: mychapterpay-3
Private GitLab Repository: https://gitlab.com/mychapterpay/mychapterpay
The Specific Commit Hash: 88294a93
You and the Vercel engineering team have my explicit permission to access our GitLab repository and the Vercel project mychapterpay-3 for the sole purpose of debugging this platform-specific authentication issue.
The bug is 100% reproducible on every deployment of that project. An engineer can simply deploy the production branch, log in with any user, and observe the 401 Unauthorized errors on all subsequent page navigations. The same code works perfectly when run locally in Docker.
We believe this is the final piece of information your team needs to investigate. We are looking forward to their findings.
Thank you.
Hi @mychapterpay, our preliminary check says nothing unusual in the environment variables for your project. I won’t be able to access the repo you shared as it is private and the minimal reproducible repo is required.
About the 401 Unauthorized requests: what auth solution are you using? I tried registering on your website and it seems like the backend is on some other origin hence requests are failing due to CORS. It maybe working locally because the origin (localhost) is same and doesn’t cause CORS issues.