DEV Community: fixkit ai

"Invalid API key" or undefined env vars on Vercel: how to fix it

fixkit ai — Sun, 18 Oct 2026 23:52:10 +0000

Your app works on your machine. You deploy to Vercel and get one of these:

Error: supabaseUrl is required.
AuthApiError: Invalid API key
OpenAI API error: 401 Incorrect API key provided: undefined

Or process.env.MY_KEY is simply undefined in production.

Why it happens

.env.local is not deployed (it's git-ignored, as it should be). Vercel needs its own copy.
The variable was added after the last deployment. Env vars only apply to new deployments.
It was added for the wrong environment (Production vs Preview vs Development).
It's used in browser code without the NEXT_PUBLIC_ prefix (Next.js) or VITE_ prefix (Vite).
Typos, quotes, or trailing spaces/newlines were pasted into the value.

Fix 1: add the variables in Vercel, then redeploy

Vercel â†’ Project â†’ Settings â†’ Environment Variables. Add each key, tick the environments that need it, then redeploy (Deployments â†’ â‹¯ â†’ Redeploy). Or use the CLI:

vercel env add NEXT_PUBLIC_SUPABASE_URL production
vercel env pull .env.local   # pulls Development values (add --environment=production for prod)

Fix 2: use the right prefix for browser code

// Next.js: inlined at BUILD time, visible in the browser
const url = process.env.NEXT_PUBLIC_SUPABASE_URL!;

// Vite
const url = import.meta.env.VITE_SUPABASE_URL;

Public prefixes are baked in at build time, which is another reason a redeploy is required.

Fix 3: keep secrets server-side

Secret keys (SUPABASE_SERVICE_ROLE_KEY, OPENAI_API_KEY, STRIPE_SECRET_KEY) must not get a public prefix. Anything with NEXT_PUBLIC_ or VITE_ ends up in the JavaScript sent to every visitor. Use secrets only in Route Handlers, Server Actions or API routes:

// app/api/chat/route.ts
export async function POST(req: Request) {
  const key = process.env.OPENAI_API_KEY; // server only
  // ...
}

Fix 4: fail fast with a clear message

function requireEnv(name: string) {
  const v = process.env[name];
  if (!v) throw new Error(`Missing env var: ${name}`);
  return v;
}

For NEXT_PUBLIC_ variables in client code, reference them literally (process.env.NEXT_PUBLIC_X). Dynamic lookups like process.env[name] aren't inlined in the browser.

Fix 5: check the value itself

Re-copy the key from the provider dashboard. Remove quotes and trailing spaces. Make sure it's the key for the right project (for example, the Supabase anon or sb_publishable_â€¦ key in the client, never the service role or sb_secret_â€¦ key).

FAQ

I added it but it's still undefined. Did you redeploy? Is it ticked for Production?

Is the Supabase anon key safe to expose? It's designed to be public, but only if Row Level Security is enabled on your tables.

Originally published on FixKit AI. Deploy failing for a different reason? See why v0/Bolt apps fail on Vercel, or paste the error into the free FixKit Error Fixer (disclosure: I built it).

Supabase RLS errors in Lovable and Bolt apps (and how to fix them safely)

fixkit ai — Sun, 18 Oct 2026 23:52:01 +0000

If you built your app with Lovable or Bolt on top of Supabase, sooner or later you'll see this:

new row violates row-level security policy for table "todos"

That's Postgres error code 42501. Its quieter cousin is worse: a select that returns [] with no error, even though the table clearly has rows.

Why it happens

When Row Level Security (RLS) is enabled and no policy allows an action, Supabase blocks it. Common causes in AI-built apps:

RLS is enabled but no insert/select policy exists
The user isn't logged in, so auth.uid() is null
The insert doesn't set user_id, or sets it to a different value
An update policy is missing its with check

Reads and writes fail differently. A blocked select doesn't throw; rows are filtered out and you get []. A blocked insert throws the error above.

Fix 1: add owner-based policies

Run this in the Supabase SQL editor (rename todos to your table):

alter table public.todos enable row level security;

create policy "Users read own todos" on public.todos

  for select to authenticated using ((select auth.uid()) = user_id);

create policy "Users insert own todos" on public.todos

  for insert to authenticated with check ((select auth.uid()) = user_id);

create policy "Users update own todos" on public.todos

  for update to authenticated

  using ((select auth.uid()) = user_id) with check ((select auth.uid()) = user_id);

create policy "Users delete own todos" on public.todos

  for delete to authenticated using ((select auth.uid()) = user_id);

Fix 2: fill in `user_id` automatically

alter table public.todos alter column user_id set default auth.uid();

Fix 3: make sure the user is actually signed in

const { data: { user } } = await supabase.auth.getUser();

if (!user) throw new Error('Not signed in');

await supabase.from('todos').insert({ title, user_id: user.id });

Don't "fix" it by disabling RLS or shipping the service_role key

The service_role key (and the newer sb_secret_... keys) bypasses RLS entirely. Keep it on the server only, never in frontend code. The browser should only use the anon or publishable key, and that key is only safe because RLS limits what it can do.

Prompt to paste into Lovable or Bolt

Write Supabase RLS policies so authenticated users can only select, insert, update, and delete rows where user_id = auth.uid(). Don't disable RLS and don't use the service_role key in the client.

FAQ

Why do I get empty results instead of an error? RLS filters select results silently. With no policy, you get zero rows.

Is a public read policy OK? Yes, for genuinely public data: for select to anon, authenticated using (true).

Originally published on FixKit AI. If you're seeing a different error, paste it into the free FixKit Error Fixer (disclosure: I built it). Related: CORS errors when a Lovable app calls an API.

DEV Community: fixkit ai

"Invalid API key" or undefined env vars on Vercel: how to fix it

Why it happens

Fix 1: add the variables in Vercel, then redeploy

Fix 2: use the right prefix for browser code

Fix 3: keep secrets server-side

Fix 4: fail fast with a clear message

Fix 5: check the value itself

FAQ

Supabase RLS errors in Lovable and Bolt apps (and how to fix them safely)

Why it happens

Fix 1: add owner-based policies

Fix 2: fill in user_id automatically

Fix 3: make sure the user is actually signed in

Don't "fix" it by disabling RLS or shipping the service_role key

Prompt to paste into Lovable or Bolt

FAQ

Fix 2: fill in `user_id` automatically