How to find your Supabase service role key (and 5 other Supabase pages buried 3 clicks deep)

Short answer: your Supabase service role key lives at https://supabase.com/dashboard/project/_/settings/api — sign in, pick your project, and the service_role key is in the "Project API keys" section. Treat it like a database password. Never ship it to the browser.

If that's all you came for, you're free to go. If you also want to know where the other five buried Supabase pages are, keep reading.

Why this key in particular is hard to find

The Supabase dashboard is one of the better-looking dev tool UIs on the market. It also has the deepest settings tree of any tool I use. Almost every important page is at least three clicks deep, and the URL is the same prefix forever, so muscle memory doesn't help much.

Specifically: every project URL starts with supabase.com/dashboard/project/{ref}/.... That {ref} slug is a random hash like abcdefghijklmnop, which is great for security and terrible for bookmarks across projects. Supabase has a handy trick for this — you can use _ instead of the project ref and Supabase will redirect you to whichever project you most recently opened. The URLs below all use the _ form.

The 6 Supabase pages I lose constantly

1. API keys (the one you came for)

supabase.com/dashboard/project/_/settings/api

What lives here:

• Project URL — https://abc.supabase.co. Your client uses this.
• anon / public key — safe to ship to the browser. Used by RLS-protected endpoints.
• service_role key — secret. Bypasses RLS entirely. Server-side only. If you leak this, you've effectively leaked your entire database.

A nice rule: anywhere this key appears in your codebase, the surrounding file should be impossible to import from a client component. In Next.js that means importing server-only at the top of the file. In other frameworks, name the file *.server.ts and lint against client imports.

2. Connection string (Postgres-direct)

supabase.com/dashboard/project/_/settings/database

The "Connection string" section. There are three of them now and the difference matters:

• Direct — use for migrations and CLI tools. Doesn't work in serverless.
• Session pooler — use this from serverless functions if you need transactions.
• Transaction pooler — the default for most serverless workloads. Cheapest, most scalable, but no prepared statements.

If your ORM is throwing weird "prepared statement does not exist" errors in production but works locally, you almost certainly grabbed the wrong one. Drizzle, Prisma, and Kysely all have docs about which to use; read them before you guess.

3. Auth users

supabase.com/dashboard/project/_/auth/users

You'll come here a lot in the first month: testing signup flows, killing test accounts, manually verifying emails. The search is per-page rather than across all users, which is mildly annoying.

The page right next to it — providers — is where you turn on Google / GitHub / Apple OAuth. Worth bookmarking separately.

4. Edge functions

supabase.com/dashboard/project/_/functions

Where you deploy Deno-based serverless functions. The list page is fine; the page you actually need is each function's logs. Buried one click further. The deploy UI is mostly CLI-driven now (supabase functions deploy) so this page is mostly for monitoring.

5. Storage

supabase.com/dashboard/project/_/storage/buckets

If you're storing user uploads, this is where buckets live, where you set them public/private, and where you set RLS policies for the storage API.

The thing that bites everyone exactly once: storage policies are separate from database RLS policies. You can have a perfect RLS policy on your profiles table and still leak avatar uploads because you didn't set the storage policy. There's a UI for it under each bucket.

6. Logs explorer

supabase.com/dashboard/project/_/logs/explorer

The single most underused Supabase page. It's basically SQL-over-your-logs. When your edge function is failing and the logs UI on the function itself is unhelpful, the logs explorer lets you write actual queries against the log stream.

If you've never opened it, open it once and stare at the schema sidebar for two minutes. It'll pay for itself.

A pattern: settings live in three places, not one

If you're new to Supabase, here's the mental model that helps:

1. Project settings — auth providers, database connection, API keys, integrations. URL pattern: /project/_/settings/*.
2. Database — the actual data, plus RLS, triggers, functions. URL pattern: /project/_/database/* for plumbing, /project/_/editor for the table editor.
3. Auth / Storage / Functions — each has its own top-level section because they each have their own data model that lives alongside Postgres.

Almost every "where is X" question reduces to "is X plumbing (settings), data (editor), or a separate domain (auth/storage/functions)?"

Supabase is great. The settings UI is not.

To be clear: I like Supabase a lot. It's the best open-source-flavored Postgres-plus-auth-plus-storage on the market, and the team ships fast. But the navigation hasn't kept up with the surface area, and the gap is most visible when you've used three different projects in a week and your muscle memory is a fight against three different project refs.

That's the gap a cross-app ⌘K palette closes. Type "supabase api", hit enter, you're on the API settings page. No nav, no clicks, no _ trick.

If you keep losing dashboard pages, that's literally what devlinkspad is for. ⌘K → devlinkspad.com.

---

Related:

• Where is the Stripe webhook URL? (And every other Stripe page you keep losing)
• The 2026 vibe-coder stack: 14 dashboards in one keystroke
• Supabase deep links on devlinkspad → · Neon deep links →