By Most Supabase Edge Functions running in production have no authentication. That’s not an assumption — Supabase’s own analysis of deployed functions found the same auth setup being rebuilt from scratch in function after function, and AI-generated scaffolds often skip it entirely. The newly released @supabase/server package (public beta, May 2026) is the fix: authentication that executes before your handler is ever called.
The Problem It’s Solving
Edge Functions run at public URLs. Anyone with that URL can invoke your function unless you explicitly verify the caller. The old approach put that responsibility entirely on you: extract the Authorization header, validate the JWT, construct an RLS-scoped client, handle the error cases — and then, finally, write the code you actually opened the file to write. Repeat this in every function, and you’ll inevitably copy-paste the pattern slightly wrong, or skip it entirely under deadline pressure.
AI coding agents have made this worse. When you ask Claude Code, Antigravity, or Codex to scaffold an edge function, auth is an afterthought the agent may or may not include. One developer’s scan of their deployed Supabase project found that eight out of nine AI-scaffolded edge functions had zero authentication checks.
How @supabase/server Handles Authentication
The shift is conceptual before it’s technical. With @supabase/server, you don’t write auth code — you declare an auth requirement. The withSupabase wrapper handles JWT validation, credential rejection, and client construction before your handler runs. If auth fails, the request stops there. Your business logic only ever sees authenticated requests.
Every handler receives a ctx object containing two pre-configured clients:
ctx.supabase— an RLS-scoped client automatically tied to the authenticated user’s sessionctx.supabaseAdmin— a service-role client for privileged operations that bypass RLS
The before-and-after is stark. Here’s the typical auth boilerplate you’re writing today:
export default async function handler(req: Request) {
const authHeader = req.headers.get('Authorization')
if (!authHeader) return new Response('Unauthorized', { status: 401 })
const token = authHeader.replace('Bearer ', '')
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY)
const { data: { user }, error } = await supabase.auth.getUser(token)
if (error || !user) return new Response('Unauthorized', { status: 401 })
const userClient = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, {
global: { headers: { Authorization: authHeader } }
})
// Finally: your actual business logic
const { data } = await userClient.from('items').select('*')
return Response.json(data)
}And here’s the same function with @supabase/server:
import { withSupabase } from '@supabase/server'
export default withSupabase({ auth: 'user' }, async (req, ctx) => {
const { data } = await ctx.supabase.from('items').select('*')
return Response.json(data)
})That’s not a toy example. The auth boilerplate is gone, and everything that was in it is still happening — just handled by the library before your code runs.
The Four Auth Modes
@supabase/server covers the four scenarios you actually encounter in production:
auth: 'user'— For functions called by signed-in users. The platform validates the session JWT; your handler gets an RLS-scoped client tied to that user.auth: 'secret'— For server-to-server calls: cron jobs, internal workers,pg_nethooks. Validates against a secret key from your dashboard. Handler gets an admin client.auth: 'publishable'— For public endpoints where the anon key is the right credential. Useful for rate-limited reads behind RLS.auth: 'none'— For external webhooks (Stripe, GitHub) that bring their own signature scheme. The SDK skips credential validation; you verify the provider’s HMAC inside the handler yourself.
When a single endpoint needs to accept multiple caller types, array syntax handles it: auth: ['user', 'secret']. First match wins. A missing credential falls through to the next mode; an invalid credential rejects immediately with no silent downgrade.
Where It Runs
The package ships with adapters for every runtime that implements the Web API Request/Response pattern: Supabase Edge Functions (Deno), Cloudflare Workers, Vercel Functions, Hono, and Bun. One install, one mental model, across all of them. If you’re splitting a project across Cloudflare Workers for low-latency routes and Supabase Edge Functions for database-heavy operations, you don’t have to learn two different auth patterns.
Not the Same as @supabase/ssr
If you’re already using @supabase/ssr for a Next.js or SvelteKit project, these packages do different things. @supabase/ssr manages cookie-based session handling for SSR frameworks. @supabase/server handles stateless, header-based auth for edge and serverless runtimes. You can — and often should — use both in the same project. They are not replacements. Deeper integration between the two is on Supabase’s roadmap.
Status and How to Try It
@supabase/server is in public beta. The API surface will change. Supabase is actively collecting feedback on adapter patterns and edge cases before locking down the interface. AWS Lambda and a full Node.js adapter are listed as in progress. If you’re building on Edge Functions or Workers today, this is stable enough to use — just don’t treat the API as final yet.
npm install @supabase/serverThe GitHub repository has framework-specific examples for each supported runtime. The official announcement post walks through the full API surface and the design reasoning behind each auth mode. For the current state of Edge Function auth without this package, the Supabase auth documentation shows what you’re replacing.
Who Should Install It
If you’re writing Supabase Edge Functions today, install it. If you’re running Cloudflare Workers or Vercel Functions that talk to a Supabase backend, install it. The boilerplate it removes is code you’d otherwise write by hand — and get slightly wrong — in every function you ship.
If you’re on Next.js App Router with @supabase/ssr and not touching Edge Functions or Workers, wait for the deeper integration.
The real value isn’t the lines of code saved. It’s that auth becomes a guardrail rather than a reminder. You can’t accidentally forget to add it — you have to explicitly opt out with auth: 'none'. In a world where AI agents are scaffolding half your codebase, that’s the right default.
