Framework guides

Use Da8a with Next.js

Use Da8a from Next.js in client components, server components and route handlers with supabase-js. Keep the anon key public and the service key server-side.

Before you start

  • A Da8a project (the Overview page shows the project URL and anon key)
  • A table to query; the quickstart creates a todos table with Row Level Security

Install the client

shell
$ npm i @supabase/supabase-js

Create the client

lib/supabase.ts
import { createClient } from '@supabase/supabase-js'
export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
)

The anon key is safe in client code as long as Row Level Security is on for your tables. Never ship the service key to the browser: it bypasses RLS.

Server-only access

In route handlers or server actions that need full access, create a second client with the service key from a server-only variable (no NEXT_PUBLIC_ prefix), and check who is calling first.

app/api/stats/route.ts
import { createClient } from '@supabase/supabase-js'
const admin = createClient(process.env.SUPABASE_URL!, process.env.SERVICE_KEY!)
export async function GET() {
  const { count } = await admin.from('todos').select('*', { count: 'exact', head: true })
  return Response.json({ count })
}

Host it

Deploy the frontend on Chapong and link it to the project: the URL, anon key and auth redirect URLs are kept in sync for you, including on preview deploys.

Questions

Do SSR auth helpers work?

Da8a exposes the same auth API as Supabase, so cookie-based helpers built on supabase-js are expected to work; test sign-in on a preview deploy before switching.

Which variables are public?

Only NEXT_PUBLIC_ ones. Never prefix the service key.

Updated 2026-10-23.