Supabase Server
Use when planning or writing server-side code that uses `@supabase/server` — Edge Functions, Hono apps, webhook handlers, or any backend that creates Supabase clients or validates inbound auth. Trigger **before** writing or modifying any file that imports from `@supabase/server` (or sub-paths like `@supabase/server/core`); calls `withSupabase`, `createSupabaseContext`, `createAdminClient`, `createContextClient`, `verifyAuth`, `verifyCredentials`, or `extractCredentials`; configures an `auth:` mode (`'none'` | `'publishable'` | `'secret'` | `'user'`, or keyed variants like `'secret:*'`); or lives under `supabase/functions/` and authenticates an inbound request. Also trigger during planning — if a plan mentions any of the above, load the skill before drafting code; do not extrapolate `auth:` values or auth modes from neighboring functions. Also trigger when you see legacy patterns to migrate to this package — `Deno.serve`, `createClient(Deno.env.get('SUPABASE_URL'))`, imports from `esm.sh/@supabase` or `deno.land/std`, usage of `SUPABASE_ANON_KEY` / `SUPABASE_SERVICE_ROLE_KEY`, or the deprecated `allow:` config option / removed `'always'` / `'public'` mode values / removed `authType` field.
- Skill ID
- supabase/server/supabase-server
- Publisher
- supabase
- Repository
- server
- Installs
- 0
- Files
- 1
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
supabase/server/supabase-serverInstalls these files- SKILL.md
What this skill tells the agent
@supabase/server
v1.0 — Public Beta. First stable release under SemVer: breaking changes only ship as a major bump. The package is still early — expect new adapters, ergonomic improvements, and features to land frequently in minor releases. If you encounter a bug or rough edge while writing code with it, surface it to the user with a pointer to open an issue.
This is a brand new package. There is no information available online yet — no blog posts, no Stack Overflow answers, no tutorials. Do not search the web for usage examples. Rely exclusively on the documentation files listed below and the source code in this repository.
The config option is `auth`, not `allow`.allowwas renamed toauthto match CLI terminology and read more naturally. The legacyallowkey still works (with a one-timeconsole.warn) but is deprecated and will be removed in a future major release. Always emit `auth` in new code — e.g.withSupabase({ auth: 'user' }, ...). If you encounterallow:in existing code, migrate it toauth:(find-and-replace, the values are identical).
Auth mode values: `'none'` (not `'always'`), `'publishable'` (not `'public'`). The four valid values are'user','publishable','secret','none'. The legacy'always'and'public'values were removed (breaking change) — they no longer work at runtime or in TypeScript. Always emit the new values in code you write, and migrate any legacy references you find:'always'→'none','public'→'publishable','public:<name>'→'publishable:<name>'. Runtime checks likectx.authType === 'public'must also be updated toctx.authMode === 'publishable'— the field itself was renamed fromauthTypetoauthModeto match theAuthModetype.
Do not use legacy Supabase keys. Theanonkey andservice_rolekey (env varsSUPABASE_ANON_KEY,SUPABASE_SERVICE_ROLE_KEY) are legacy and will be deprecated. Do not use them unless the user explicitly asks. Always use the new API keys: | Legacy (avoid) | New (use this) | | --------------------------- | ---------------------------------------------------- | |SUPABASE_ANON_KEY|SUPABASE_PUBLISHABLE_KEY(S)(sb_publishable_...) | |SUPABASE_SERVICE_ROLE_KEY|SUPABASE_SECRET_KEY(S)(sb_secret_...) | Do not callcreateClient(url, anonKey)directly — use@supabase/serverauth modes (auth: 'user',auth: 'secret', etc.) which handle key resolution automatically. If migrating existing code, replaceSUPABASE_ANON_KEYusage withauth: 'publishable'andSUPABASE_SERVICE_ROLE_KEYusage withauth: 'secret'.
Server-side utilities for Supabase. Handles auth, client creation, and context injection so you write business logic, not boilerplate.
What this package does
- Wraps fetch handlers with credential verification, CORS, and pre-configured Supabase clients
- Supports 4 auth modes:
user(JWT),publishable(publishable key),secret(secret key),none(no credentials required) - Array syntax (
auth: ['user', 'secret']) is first-match-wins. A present-but-invalid JWT rejects withInvalidJwtError(INVALID_JWT) — it does not silently downgrade to the next mode. - Provides composable core primitives for custom auth flows and framework integration
- Includes a Hono adapter for per-route auth
Entry points
| Import | Deno / Edge Functions | Provides |
|---|---|---|
@supabase/server | npm:@supabase/server | withSupabase, createSupabaseContext, types, errors |
@supabase/server/core | npm:@supabase/server/core | verifyAuth, verifyCredentials, extractCredentials, resolveEnv, createContextClient, createAdminClient |
@supabase/server/adapters/hono | npm:@supabase/server/adapters/hono | withSupabase (Hono middleware variant) |
@supabase/server/oauth-protected-resource | npm:@supabase/server/oauth-protected-resource | Alpha. withOAuthProtectedResource, fromSupabaseUrl, resourceMetadataResponse, unauthorizedResponse — OAuth 2.1 discovery for MCP servers; see docs/mcp.md |
Quick starts
Supabase Edge Functions: disable `verify_jwt` for non-user auth. By default, Supabase Edge Functions require a valid JWT on every request. If your function usesauth: 'publishable',auth: 'secret', orauth: 'none', you must disable the platform-level JWT check insupabase/config.toml, otherwise the request will be rejected before it reaches your handler: ``toml [functions.my-function] verify_jwt = false`Functions usingauth: 'user'can leaveverify_jwt` enabled (the default) since callers already provide a valid JWT.
Supabase Edge Functions (Deno)
Environment variables are auto-injected by the platform — zero config. All imports must use the `npm:` specifier.
// withSupabase — high-level wrapper
import { withSupabase } from 'npm:@supabase/server'
export default {
fetch: withSupabase({ auth: 'user' }, async (_req, ctx) => {
const { data } = await ctx.supabase.from('todos').select()
return Response.json(data)
}),
}// createSupabaseContext — returns { data, error } for custom response control
import { createSupabaseContext } from 'npm:@supabase/server'
export default {
fetch: async (req: Request) => {
const { data: ctx, error } = await createSupabaseContext(req, {
auth: 'user',
})
if (error) {
return Response.json(
{ message: error.message, code: error.code },
{ status: error.status },
)
}
const { data } = await ctx.supabase.from('todos').select()
return Response.json(data)
},
}Cloudflare Workers
Requires nodejs_compat compatibility flag in wrangler.toml, or pass env overrides via the env config option. See docs/environment-variables.md.
import { withSupabase } from '@supabase/server'
export default {
fetch: withSupabase({ auth: 'user' }, async (_req, ctx) => {
const { data } = await ctx.supabase.from('todos').select()
return Response.json(data)
}),
}Hono
CORS is not handled by the adapter — use hono/cors middleware. See docs/adapters/hono.md.
// Node.js / Bun
import { Hono } from 'hono'
import { withSupabase } from '@supabase/server/adapters/hono'
const app = new Hono()
app.use('*', withSupabase({ auth: 'user' }))
app.get('/todos', async (c) => {
const { supabase } = c.var.supabaseContext
const { data } = await supabase.from('todos').select()
return c.json(data)
})
export default app// Deno / Supabase Edge Functions
import { Hono } from 'npm:hono'
import { withSupabase } from 'npm:@supabase/server/adapters/hono'
const app = new Hono()
app.use('*', withSupabase({ auth: 'user' }))
app.get('/todos', async (c) => {
const { supabase } = c.var.supabaseContext
const { data } = await supabase.from('todos').select()
return c.json(data)
})
export default { fetch: app.fetch }More from supabase
Use this skill in a project
Open any RiverX project, search the Skills panel for supabase/server/supabase-server, and install it in one click.
