Sådan løser du 'Supabase API Key Not Found' i miljøvariabler

Sidst verificeret: 11. september 2026. Du tilføjer din Supabase URL og API-nøgle til en .env fil, genstarter appen og får stadig en fejl som “Supabase API key not found” eller Supabases egen supabaseKey is required. I de fleste tilfælde eksisterer nøglen et sted, men koden, der kalder createClient(), modtager undefined eller en tom streng.

Der er også en vigtig navneændring fra 2026 bag mange forvirrende tutorials. Supabase udfaser de gamle anon og service_role API-nøgler ved udgangen af 2026 og anbefaler nu publicerbare nøgler til offentlig/klientkode og sekret nøgler til betroet serverkode. Eksisterende gamle nøgler kan fortsætte med at fungere under migreringen, indtil du deaktiverer dem, men dit miljøvariabelnavn og din kode skal stadig matche præcist.

Den nuværende Supabase-dokumentation bruger værdier som sb_publishable_... og sb_secret_.... Se den officielle Supabase API-nøgle guide og migreringsguiden for publicerbare og sekret nøgler.

Hurtig løsning: Få variabelnavnene til at matche frameworket og koden

For en nuværende Next.js browserklient bruger Supabases officielle quickstart:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

og:

import { createClient } from '@supabase/supabase-js'

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY

if (!supabaseUrl || !supabaseKey) {
  throw new Error('Supabase environment variables are missing')
}

export const supabase = createClient(supabaseUrl, supabaseKey)

For en nuværende Vite/React browserklient bruger Supabases officielle React quickstart:

VITE_SUPABASE_URL=https://your-project.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

og du læser dem med:

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL
const supabaseKey = import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY

For server-only kode, der virkelig har brug for udvidet adgang, viser Supabases API-nøgle guide et mønster som:

SUPABASE_URL=https://your-project.supabase.co
SUPABASE_SECRET_KEY=sb_secret_...

Placer aldrig sb_secret_... i en variabel, der er tilsigtet eksponeret til browserkode, såsom en Vite VITE_* variabel eller en Next.js NEXT_PUBLIC_* variabel. Supabase siger, at sekret nøgler omgår Row Level Security og skal forblive i udviklerkontrollerede backend-komponenter.

Trin 1: Bekræft at værdien faktisk mangler ved runtime

Begynd ikke med at regenerere nøgler eller geninstallere pakker. Bevis først, hvad din applikation modtager.

Den nuværende @supabase/supabase-js klient tjekker det andet argument, der sendes til dens klientkonstruktor, og kaster supabaseKey is required., når værdien er falsk. Du kan se denne adfærd i den officielle supabase-js kildekode.

Tilføj en midlertidig beskyttelse før createClient():

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY

console.log('Supabase URL loaded:', Boolean(supabaseUrl))
console.log('Supabase key loaded:', Boolean(supabaseKey))
console.log(
  'Key type:',
  supabaseKey?.startsWith('sb_publishable_') ? 'publishable' : 'other/missing'
)

if (!supabaseUrl || !supabaseKey) {
  throw new Error('Supabase environment variables are missing')
}

For Vite, brug den samme idé med import.meta.env.

Udskriv ikke hele sekret nøglen. Til fejlfinding er en boolean eller forventet præfiks nok. En publicerbar nøgle er designet til offentlige komponenter, men at logge fulde legitimationsoplysninger er stadig unødvendigt; en sekret nøgle må aldrig eksponeres i klientlogs.

Bemærk også, at TypeScript syntaks som process.env.MY_KEY! eller process.env.MY_KEY as string ikke skaber en manglende værdi ved runtime. Det ændrer kun, hvad TypeScript tror om typen. Hvis miljøvariablen er fraværende, modtager Supabase stadig undefined.

Selvkontrol: Hvis booleen for nøglen er false, stop med at fejlfinde Supabase tilladelser, autentificering eller Row Level Security. Applikationen har ikke indlæst konfigurationen endnu.

Trin 2: Brug den nuværende nøgletype – og gør gamle og nye navne konsistente

Åbn din Supabase projekts Connect dialog, eller gå til Settings → API Keys. Supabases nuværende dokumentation identificerer eksplicit Settings → API Keys som stedet at se alle projektets API-nøgler.

For kode, der leveres til en brugers browser, mobilapp, desktopapp eller anden offentlig komponent, skal du bruge en publicerbar nøgle. Supabase siger, at den publicerbare nøgle er sikker at eksponere, fordi databaseadgang stadig styres af grants og Row Level Security. For backend-komponenter, som du fuldt ud kontrollerer, giver en sekret nøgle udvidet adgang og omgår Row Level Security.

Migreringen fra gamle nøgler er en almindelig årsag til en “not found” fejl, fordi følgende kombinationer ikke er ækvivalente som miljøvariabelnavne:

En ældre variabel som NEXT_PUBLIC_SUPABASE_ANON_KEY er ikke automatisk ugyldig. Hvis dit projekt stadig har en aktiv gammel anon nøgle, og din kode læser den præcise variabel, kan den fortsætte med at fungere under Supabases migreringsperiode. Problemet er at kopiere en ny publicerbar nøgle til ét variabelnavn, mens koden stadig læser et andet.

Selvkontrol: Søg i dit projekt efter SUPABASE_. Sammenlign hvert variabelnavn i koden med de præcise navne i dine miljøfiler og implementeringsindstillinger. Støt dig ikke til hukommelsen.

Trin 3: Placer .env filen hvor dit framework faktisk indlæser den

En korrekt nøgle i den forkerte filplacering er effektivt en manglende nøgle.

Next.js: Hold .env filer i projektroden

Next.js har indbygget understøttelse for .env* filer. Dens nuværende miljøvariabel guide siger, at hvis du bruger en /src mappe, hører miljøfilerne stadig til i projektroden, ikke inde i /src. Se den officielle Next.js miljøvariabel guide.

Et typisk layout er:

my-app/
  .env.local
  package.json
  next.config.js
  app/
  src/        # if used

For browser-side kode eksponerer Next.js kun variabler, der bruger NEXT_PUBLIC_ præfikset. Disse værdier inlines i browserbunken ved build-tidspunktet.

Vite: Brug VITE_ og import.meta.env

Vite eksponerer klient miljøvariabler gennem import.meta.env. Som standard eksponeres kun navne med præfikset VITE_ til klientkode. Den officielle Vite Env Variables and Modes guide dokumenterer dette direkte.

Dette vil fungere i en Vite klient:

VITE_SUPABASE_URL=https://your-project.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

const url = import.meta.env.VITE_SUPABASE_URL
const key = import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY

Dette vil normalt være undefined i Vite browserkode:

const key = import.meta.env.SUPABASE_PUBLISHABLE_KEY

fordi det mangler det standard VITE_ eksponeringspræfiks.

Node/serverkode: Kopiér ikke browserpræfikser blindt

Serverkode læser normalt fra process.env. Hvis en nøgle ikke behøver at være tilgængelig i browseren, skal du ikke tilføje et offentligt præfiks bare for at gøre den synlig. Supabase advarer specifikt om, at sekret nøgler er backend-only.

Selvkontrol: Verificer tre ting sammen: env filen er i applikationsroden, variabelnavnet bruger det korrekte framework præfiks, og koden bruger frameworkets korrekte accessor – process.env for Next.js/Node eller import.meta.env for Vite klientkode.

Trin 4: Genstart udviklingsserveren efter ændring af miljøfiler

Miljøvariabler indlæses typisk, når udviklingsprocessen starter. Vite dokumenterer eksplicit, at .env filer indlæses ved opstart, og at du skal genstarte serveren efter ændringer.

Stop den nuværende proces og start den igen:

# Next.js
npm run dev

# Vite
npm run dev

Hvis fejlen opstod kun efter du oprettede miljøfilen, mens serveren allerede kørte, kan en genstart være hele løsningen.

Selvkontrol: Kør de midlertidige boolean tjek igen. Hvis værdierne nu er indlæst, fjern unødvendig fejlfindingsoutput og fortsæt til normal Supabase drift.

Brug en runtime beskyttelse i stedet for at skjule problemet med TypeScript

Et nyttigt produktionsmønster er at fejle med en klar konfigurationsbesked før kald til Supabase:

import { createClient } from '@supabase/supabase-js'

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY

if (!supabaseUrl) {
  throw new Error('NEXT_PUBLIC_SUPABASE_URL is missing')
}

if (!supabaseKey) {
  throw new Error('NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY is missing')
}

export const supabase = createClient(supabaseUrl, supabaseKey)

Dette er bedre end:

createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
)

når du fejlfinder, fordi non-null assertion kan skjule TypeScript advarslen uden at ændre runtime værdien.

Hvis det virker lokalt men fejler efter implementering

Dette er normalt et implementeringsmiljøproblem, ikke et Supabase projektproblem.

Lokale .env.local filer committes normalt ikke til Git – og bør ikke behandles som en produktions mekanisme til levering af hemmeligheder. Konfigurer de samme variabelnavne i din hostingudbyders projektindstillinger.

For eksempel dokumenterer Vercel separate Production, Preview og Development miljøer. Det angiver også, at ændringer i miljøvariabler kun gælder for nye implementeringer, så du skal genimplementere efter tilføjelse eller ændring. Se Vercels officielle miljøvariabel administrationsguide.

Tjek:

• Er variablen defineret for Production, ikke kun Preview?
• Matcher navnet præcist koden?
• Blev der oprettet en ny implementering efter variablen blev tilføjet?
• Var den offentlige variabel til stede, da klientbunken blev bygget?

Next.js offentlige variabler er build-time værdier

Next.js dokumenterer, at NEXT_PUBLIC_* variabler inlines i browser JavaScript ved build-tidspunktet. Efter appen er bygget, ændrer ændring af runtime miljøet ikke disse værdier i den eksisterende klientbunke. Hvis du bygger et Docker image uden NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY og senere injicerer den kun, når containeren starter, kan browserkoden stadig indeholde den manglende build-time værdi.

Løsning: Lever offentlige Supabase værdier under bygningen, der producerer klientbunken, eller redesign applikationen til at levere runtime konfiguration gennem en serverkontrolleret mekanisme.

Vite erstatter også klient env værdier under bygningen

Vites dokumentation siger, at import.meta.env konstanter erstattes statisk under bundling. Derfor, hvis lokal udvikling virker, men produktionsbunken ikke gør, skal du verificere at VITE_SUPABASE_URL og VITE_SUPABASE_PUBLISHABLE_KEY eksisterede i build miljøet – ikke kun på maskinen, der senere serverer de statiske filer.

Monorepos: Tjek hvilken mappe der faktisk er app-roden

Et monorepo kan indeholde:

repo/
  package.json
  apps/
    web/
      package.json
      .env.local
      app/
  packages/
    ui/

Hvis Next.js eller Vite kommandoen kører med apps/web som sin applikationsrod, kan en miljøfil placeret kun i repo/.env.local ikke være den fil, frameworket indlæser. Vites envDir er som standard projektroden, og Next.js forventer sine .env* filer i Next.js projektroden.

Løsning: Identificér mappen, der indeholder applikationens package.json og framework konfiguration, og placer env filen hvor den app forventer det, eller konfigurer eksplicit miljømappen, når frameworket understøtter det.

Supabase Edge Functions bruger forskellige nuværende standard variabelnavne

Hvis fejlen er inde i en Supabase Edge Function, skal du ikke blindt kopiere et Next.js eller Vite eksempel.

Supabases nuværende Edge Functions miljøvariabel dokumentation lister disse standard hemmeligheder, blandt andre:

• SUPABASE_URL
• SUPABASE_DB_URL
• SUPABASE_PUBLISHABLE_KEYS
• SUPABASE_SECRET_KEYS
• SUPABASE_JWKS

Bemærk at SUPABASE_PUBLISHABLE_KEYS og SUPABASE_SECRET_KEYS er flertalsformer. Supabases migreringsguide forklarer, at disse nye variabler indeholder JSON objekter nøglet efter API-nøgle navnet. For en standard sekret nøgle:

const secretKeys = JSON.parse(
  Deno.env.get('SUPABASE_SECRET_KEYS') ?? '{}'
)

const secretKey = secretKeys['default']

if (!secretKey) {
  throw new Error('Default Supabase secret key is missing')
}

Under migrering kan gamle Edge Function variabler som SUPABASE_ANON_KEY og SUPABASE_SERVICE_ROLE_KEY eksistere ved siden af de nye nøgleordbøger. Antag ikke, at variabelnavnet fra en gammel function tutorial matcher den nye nøgletype, du lige har oprettet.

Løs ikke fejlen ved at eksponere en sekret nøgle

En fristende “løsning” er at tilføje NEXT_PUBLIC_ eller VITE_ til en serverhemmelighed, så browseren endelig kan læse den. Det kan eliminere manglende variabel fejlen mens det skaber et sikkerhedsproblem.

Supabases nuværende API-nøgle guide er eksplicit:

• Publicerbar nøgle: beregnet til offentlige komponenter som browser og mobilapplikationer.
• Sekret nøgle: beregnet kun til backend-komponenter, du kontrollerer; den omgår Row Level Security.

Hvis en sekret nøgle er blevet eksponeret i kildekode, en offentlig bunke, et skærmbillede eller et repository, skal du fjerne eller rotere den gennem Supabases API Keys indstillinger i stedet for blot at omdøbe miljøvariablen.

Almindelige symptomer og den hurtigste tjek

Endelig selvkontrol: Verificér konfigurationen i den rigtige rækkefølge

Før du erklærer problemet løst, kør denne tjekliste:

1. Bekræft at Supabase Project URL kommer fra det projekt, du faktisk har til hensigt at bruge.
2. For browser/klientkode, bekræft at du bruger en nuværende publicerbar nøgle eller en stadig aktiv gammel anon nøgle – ikke en sekret nøgle.
3. Bekræft at koden og miljøfilen bruger de samme variabelnavne.
4. For Next.js klientkode, brug NEXT_PUBLIC_* og direkte process.env.VARIABLE_NAME referencer.
5. For Vite klientkode, brug VITE_* og import.meta.env.VARIABLE_NAME.
6. Hold .env.local i applikationsroden i stedet for inde i /src.
7. Genstart udviklingsserveren efter redigering af miljøfiler.
8. For produktion, sæt værdierne i det korrekte implementeringsmiljø og rebuild/redeploy.
9. Log eller eksponér ikke sb_secret_... nøgler.
10. Fjern midlertidige debug logs, når konfigurationen er bekræftet.

Når createClient() initialiserer uden manglende nøgle fejl, er miljøvariabelproblemet løst. Hvis den næste Supabase anmodning returnerer en autorisations-, Row Level Security- eller tabeltilladelsesfejl, skal du behandle det som et separat problem. En gyldig API-nøgle garanterer ikke, at kalderen har tilladelse til at læse eller ændre hver række; Supabase adskiller intentionelt API-nøgle identifikation fra brugerautentificering og databaseautorisation.

Den holdbare løsning er ikke “omdøb nøglen indtil den virker.” Det er at aligne fire ting: den nuværende Supabase nøgletype, miljøvariabelnavnet, frameworkets eksponeringsregler og miljøet, hvori appen faktisk bygges eller eksekveres. Når disse er enige, modtager Supabase klienten en rigtig nøgle i stedet for undefined, og den vildledende konfigurationsløkke slutter.