[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live)

[Feedback](/c/feedback/8)

# Bug: API Key Migration issue

268 views · 0 likes · 1 post


Montaguejacobs (@montaguejacobs) · 2025-11-19

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](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)

* 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)

1. Rotated Supabase service-role key and updated Vercel env `SUPABASE_SERVICE_ROLE_KEY`.

2. Triggered production redeploy → `/api/delete-user` still showed mask of old key (`eyJh…`).

3. Repeated redeploys, cleared cache, even re-ran builds—still old key.

4. Added logging to function to print masked secrets; confirmed old value persisted.

5. Created env var with new name (`SUPABASE_SERVICE_ROLE_KEYY`), updated code to read it, redeployed → function immediately reported new `sb_s…` mask and succeeded.

6. 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

1. Create a simple API route that logs [process.env.MY_SECRET](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html).

2. Deploy with `MY_SECRET=valueA`; hit the route to confirm.

3. Change the env var to `valueB` (same name), redeploy.

4. Hit the route again—it still logs `valueA`.

5. Rename the env var (e.g., `MY_SECRET_V2=valueB`) and update code to read the new name; redeploy.

6. 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.