Så åtgärdar du felet 'Supabase API Key Not Found' i miljövariabler

Senast verifierad: 11 september 2026. Du lägger till din Supabase-URL och API-nyckel i en .env-fil, startar om appen och får fortfarande ett fel som “Supabase API key not found” eller Supabases eget supabaseKey is required. I de flesta fall finns nyckeln någonstans, men koden som anropar createClient() tar emot undefined eller en tom sträng.

Det finns också en viktig namnändring från 2026 som ligger bakom många förvirrande handledningar. Supabase fasar ut de äldre API-nycklarna anon och service_role i slutet av 2026 och rekommenderar nu publicerbara nycklar för publik/klientkod och sekreta nycklar för betrodd serverkod. Befintliga äldre nycklar kan fortsätta fungera under migreringen tills du inaktiverar dem, men namnet på din miljövariabel och din kod måste fortfarande matcha exakt.

Den aktuella Supabase-dokumentationen använder värden som sb_publishable_... och sb_secret_.... Se den officiella Supabase-guiden för API-nycklar och migreringsguiden för publicerbara och sekreta nycklar.

Snabbfix: se till att variabelnamnen matchar ramverket och koden

För en aktuell Next.js webbläsarklient använder Supabases officiella snabbstart:

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

och:

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)

För en aktuell Vite/React webbläsarklient använder Supabases officiella React-snabbstart:

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

och du läser dem med:

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

För server-only kod som verkligen behöver utökad åtkomst visar Supabases API-nyckelguide ett mönster som:

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

Placera aldrig sb_secret_... i en variabel som avsiktligt exponeras för webbläsarkod, som en Vite VITE_*-variabel eller en Next.js NEXT_PUBLIC_*-variabel. Supabase säger att sekreta nycklar kringgår Row Level Security och måste hållas i backendkomponenter som utvecklaren kontrollerar.

Steg 1: bekräfta att värdet faktiskt saknas vid körning

Börja inte med att generera nya nycklar eller installera om paket. Bevisa först vad din applikation tar emot.

Den aktuella @supabase/supabase-js-klienten kontrollerar det andra argumentet som skickas till klientkonstruktorn och kastar supabaseKey is required. när värdet är falskt. Du kan se detta beteende i den officiella supabase-js-källkoden.

Lägg till en tillfällig kontroll före 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')
}

För Vite, använd samma idé med import.meta.env.

Skriv inte ut hela den sekreta nyckeln. För felsökning räcker en boolean eller ett förväntat prefix. En publicerbar nyckel är designad för publika komponenter, men att logga fullständiga autentiseringsuppgifter är fortfarande onödigt; en sekret nyckel får aldrig exponeras i klientloggar.

Notera också att TypeScript-syntax som process.env.MY_KEY! eller process.env.MY_KEY as string inte skapar ett saknat värde vid körning. Det ändrar bara vad TypeScript tror om typen. Om miljövariabeln saknas tar Supabase fortfarande emot undefined.

Självkontroll: Om booleans för nyckeln är false, sluta felsöka Supabase-behörigheter, autentisering eller Row Level Security. Applikationen har inte laddat konfigurationen ännu.

Steg 2: använd aktuell nyckeltyp – och gör gamla och nya namn konsekventa

Öppna din Supabase-projekts Connect-dialogruta, eller gå till Settings → API Keys. Supabases aktuella dokumentation identifierar uttryckligen Settings → API Keys som platsen för att visa alla projektets API-nycklar.

För kod som levereras till en användares webbläsare, mobilapp, skrivbordsapp eller annan publik komponent, använd en publicerbar nyckel. Supabase säger att den publicerbara nyckeln är säker att exponera eftersom databasåtkomst fortfarande styrs av behörigheter och Row Level Security. För backendkomponenter som du helt kontrollerar ger en sekret nyckel utökad åtkomst och kringgår Row Level Security.

Migreringen från äldre nycklar är en vanlig orsak till ett “not found”-fel eftersom följande kombinationer inte är ekvivalenta som miljövariabelnamn:

En äldre variabel som NEXT_PUBLIC_SUPABASE_ANON_KEY är inte automatiskt ogiltig. Om ditt projekt fortfarande har en aktiv äldre anon-nyckel och din kod läser exakt den variabeln, kan den fortsätta fungera under Supabases migreringsperiod. Problemet är att kopiera en ny publicerbar nyckel till ett variabelnamn medan koden fortfarande läser ett annat.

Självkontroll: Sök i ditt projekt efter SUPABASE_. Jämför varje variabelnamn i koden med de exakta namnen i dina miljöfiler och distributionsinställningar. Förlita dig inte på minnet.

Steg 3: placera .env-filen där ditt ramverk faktiskt laddar den

En korrekt nyckel på fel filplats är i praktiken en saknad nyckel.

Next.js: håll .env-filer i projektroten

Next.js har inbyggt stöd för .env*-filer. Dess aktuella guide för miljövariabler säger att om du använder en /src-katalog, tillhör miljöfilerna fortfarande projektroten, inte inne i /src. Se den officiella Next.js-guiden för miljövariabler.

En typisk layout är:

my-app/
  .env.local
  package.json
  next.config.js
  app/
  src/        # om används

För webbläsarsidokod exponerar Next.js endast variabler som använder NEXT_PUBLIC_-prefixet. Dessa värden inlinjas i webbläsarbundlen vid byggtillfället.

Vite: använd VITE_ och import.meta.env

Vite exponerar klientmiljövariabler via import.meta.env. Som standard exponeras endast namn med prefixet VITE_ för klientkod. Den officiella Vite-guiden för miljövariabler och lägen dokumenterar detta direkt.

Detta fungerar 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

Detta kommer normalt att vara undefined i Vite-webbläsarkod:

const key = import.meta.env.SUPABASE_PUBLISHABLE_KEY

eftersom det saknar det standard VITE_-exponeringsprefixet.

Node/serverkod: kopiera inte webbläsarprefix blindt

Serverkod läser normalt från process.env. Om en nyckel inte behöver vara tillgänglig i webbläsaren, lägg inte till ett publikt prefix bara för att göra den synlig. Supabase varnar specifikt för att sekreta nycklar är backend-only.

Självkontroll: verifiera tre saker tillsammans: env-filen är i applikationsroten, variabelnamnet använder korrekt ramverksprefix, och koden använder ramverkets korrekta accessor – process.env för Next.js/Node eller import.meta.env för Vite-klientkod.

Steg 4: starta om utvecklingsservern efter ändringar i miljöfiler

Miljövariabler laddas vanligtvis när utvecklingsprocessen startar. Vite dokumenterar uttryckligen att .env-filer laddas vid start och att du ska starta om servern efter ändringar.

Stoppa den nuvarande processen och starta den igen:

# Next.js
npm run dev

# Vite
npm run dev

Om felet uppstod först efter att du skapade miljöfilen medan servern redan kördes, kan en omstart vara hela fixen.

Självkontroll: kör de tillfälliga boolean-kontrollerna igen. Om värdena nu är laddade, ta bort onödig felsökningsutdata och fortsätt till normal Supabase-drift.

Använd en körningskontroll istället för att dölja problemet med TypeScript

En användbar produktionsmönster är att misslyckas med ett tydligt konfigurationsmeddelande innan du anropar 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)

Detta är bättre än:

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

när du felsöker, eftersom den icke-null-assertionen kan dölja TypeScript-varningen utan att ändra värdet vid körning.

Om det fungerar lokalt men misslyckas efter distribution

Detta är vanligtvis ett problem med distributionsmiljön, inte ett Supabase-projektproblem.

Lokala .env.local-filer committas normalt inte till Git – och bör inte behandlas som en produktionsmekanism för hemlig leverans. Konfigurera samma variabelnamn i din hosting-leverantörs projektinställningar.

Till exempel dokumenterar Vercel separata Production-, Preview- och Development-miljöer. Det anges också att ändringar av miljövariabler endast gäller för nya distributioner, så du måste distribuera om efter att du lagt till eller ändrat dem. Se Vercels officiella guide för hantering av miljövariabler.

Kontrollera:

• Är variabeln definierad för Production, inte bara Preview?
• Matchar namnet exakt koden?
• Skapades en ny distribution efter att variabeln lades till?
• Fanns den publika variabeln när klientbundlen byggdes?

Next.js publika variabler är byggtidsvärden

Next.js dokumenterar att NEXT_PUBLIC_*-variabler inlinjas i webbläsar-JavaScript vid byggtillfället. Efter att appen byggts, ändrar inte runtime-miljön dessa värden i den befintliga klientbundlen. Om du bygger en Docker-avbildning utan NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY och senare injicerar den endast när containern startar, kan webbläsarkoden fortfarande innehålla det saknade byggtidsvärdet.

Fix: tillhandahåll publika Supabase-värden under bygget som producerar klientbundlen, eller omforma applikationen för att tillhandahålla runtime-konfiguration via en serverstyrd mekanism.

Vite ersätter också klientenv-värden under bygget

Vites dokumentation säger att import.meta.env-konstanter ersätts statiskt under bundling. Därför, om lokal utveckling fungerar men produktionsbundlen inte gör det, verifiera att VITE_SUPABASE_URL och VITE_SUPABASE_PUBLISHABLE_KEY fanns i byggmiljön – inte bara på maskinen som senare serverar de statiska filerna.

Monorepos: kontrollera vilken katalog som faktiskt är approten

Ett monorepo kan innehålla:

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

Om Next.js- eller Vite-kommandot körs med apps/web som applikationsrot, kan en miljöfil placerad endast i repo/.env.local inte vara den fil som ramverket laddar. Vites envDir är som standard projektroten, och Next.js förväntar sig sina .env*-filer i Next.js-projektroten.

Fix: identifiera katalogen som innehåller applikationens package.json och ramverkskonfiguration, placera sedan env-filen där appen förväntar sig den eller konfigurera explicit miljö-katalogen när ramverket stöder det.

Supabase Edge Functions använder olika aktuella standardvariabelnamn

Om felet är inuti en Supabase Edge Function, kopiera inte blindt ett Next.js- eller Vite-exempel.

Supabases aktuella dokumentation för miljövariabler för Edge Functions listar dessa standardsekreta, bland andra:

• SUPABASE_URL
• SUPABASE_DB_URL
• SUPABASE_PUBLISHABLE_KEYS
• SUPABASE_SECRET_KEYS
• SUPABASE_JWKS

Notera att SUPABASE_PUBLISHABLE_KEYS och SUPABASE_SECRET_KEYS är plural. Supabases migreringsguide förklarar att dessa nya variabler innehåller JSON-objekt nycklade efter API-nyckelnamn. För en standardsekret nyckel:

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 migreringen kan äldre Edge Function-variabler som SUPABASE_ANON_KEY och SUPABASE_SERVICE_ROLE_KEY existera vid sidan av de nya nyckelordlistorna. Anta inte att variabelnamnet från en gammal funktionshandledning matchar den nya nyckeltyp du just skapat.

Lös inte felet genom att exponera en sekret nyckel

En frestande “fix” är att lägga till NEXT_PUBLIC_ eller VITE_ till en serversekret så att webbläsaren äntligen kan läsa den. Det kan eliminera felet med saknad variabel medan det skapar ett säkerhetsproblem.

Supabases aktuella API-nyckelguide är uttrycklig:

• Publicerbar nyckel: avsedd för publika komponenter som webbläsar- och mobilapplikationer.
• Sekret nyckel: avsedd endast för backendkomponenter du kontrollerar; den kringgår Row Level Security.

Om en sekret nyckel har exponerats i källkod, en publik bundle, en skärmdump eller ett repository, ta bort eller rotera den via Supabases API Keys-inställningar istället för att bara byta namn på miljövariabeln.

Vanliga symtom och den snabbaste kontrollen

Slutlig självkontroll: verifiera konfigurationen i rätt ordning

Innan du deklarerar att problemet är löst, kör denna checklista:

1. Bekräfta att Supabases Project URL kommer från det projekt du faktiskt avser att använda.
2. För webbläsar/klientkod, bekräfta att du använder en aktuell publicerbar nyckel eller en fortfarande aktiv äldre anon-nyckel – inte en sekret nyckel.
3. Bekräfta att koden och miljöfilen använder samma variabelnamn.
4. För Next.js klientkod, använd NEXT_PUBLIC_* och direkta process.env.VARIABLE_NAME-referenser.
5. För Vite klientkod, använd VITE_* och import.meta.env.VARIABLE_NAME.
6. Håll .env.local i applikationsroten snarare än inne i /src.
7. Starta om utvecklingsservern efter redigering av miljöfiler.
8. För produktion, sätt värdena i rätt distributionsmiljö och bygg om/distribuera om.
9. Logga eller exponera inte sb_secret_...-nycklar.
10. Ta bort tillfälliga felsökningsloggar när konfigurationen är bekräftad.

När createClient() initieras utan felet med saknad nyckel, är miljövariabelproblemet löst. Om nästa Supabase-förfrågan returnerar ett auktoriserings-, Row Level Security- eller tabellbehörighetsfel, behandla det som ett separat problem. En giltig API-nyckel garanterar inte att anroparen får läsa eller ändra varje rad; Supabase separerar medvetet API-nyckelidentifiering från användarautentisering och databasauktorisation.

Den bestående fixen är inte “byt namn på nyckeln tills den fungerar”. Det är att samordna fyra saker: den aktuella Supabase-nyckeltypen, miljövariabelnamnet, ramverkets exponeringsregler och miljön där appen faktiskt byggs eller körs. När dessa överensstämmer, tar Supabase-klienten emot en riktig nyckel istället för undefined, och den vilseledande konfigurationsloopen tar slut.