After rotating our Supabase service-role key, our Vercel serverless function /api/delete-user kept receiving the old secret even though we updated the environment variable in Vercel and redeployed multiple times. The function only picked up the new value after we renamed the environment variable itself (and adjusted the code to read the new name). This points to a caching bug where existing variable names keep serving stale values.
Project / Environment
-
Vercel project: bubblebrainz
-
Framework: Vite + React, Vercel serverless API route delete-user.js
-
Region: default (was seeing issue globally)
-
Relevant env var:
SUPABASE_SERVICE_ROLE_KEY(and aliases)
Impact
-
Production account-deletion flow failed for several hours because the function called Supabase with an invalid API key.
-
Diagnostics confirmed the service-role mask returned from the Vercel function never changed, even after key rotation, redeploys, and cache-clearing steps.
-
Only workaround was to create new env var names (e.g.,
SUPABASE_SERVICE_ROLE_KEYY) and redeploy, which immediately picked up the fresh key.
Timeline (CET, Nov 17–19, 2025)
-
Rotated Supabase service-role key and updated Vercel env
SUPABASE_SERVICE_ROLE_KEY. -
Triggered production redeploy →
/api/delete-userstill showed mask of old key (eyJh…). -
Repeated redeploys, cleared cache, even re-ran builds—still old key.
-
Added logging to function to print masked secrets; confirmed old value persisted.
-
Created env var with new name (
SUPABASE_SERVICE_ROLE_KEYY), updated code to read it, redeployed → function immediately reported newsb_s…mask and succeeded. -
Renaming back to the original env var reproduced the problem (old value again).
Expected Behavior
Updating an environment variable’s value in the Vercel dashboard (or CLI) and redeploying should propagate the new value to all serverless function instances without renaming the variable.
Actual Behavior
Serverless functions continue to receive the previous value tied to the old key name, regardless of redeployments. Only introducing a new variable name forces Vercel to serve the updated secret.
Reproduction Steps
-
Create a simple API route that logs process.env.MY_SECRET.
-
Deploy with
MY_SECRET=valueA; hit the route to confirm. -
Change the env var to
valueB(same name), redeploy. -
Hit the route again—it still logs
valueA. -
Rename the env var (e.g.,
MY_SECRET_V2=valueB) and update code to read the new name; redeploy. -
Now the route logs
valueB.
Current Workaround
Use brand-new env var names each time we rotate secrets, and keep backward compatibility in code by checking both names. This is brittle and clutters the environment with one-off names.
Request
Please investigate why updated environment variable values aren’t propagated to serverless functions under the same key name, and ensure redeployments flush the cached value. A fix would prevent teams from having to rename secrets (and change code) every time credentials rotate.