# Architecture and API Keys — Supabase

Source: https://www.skillbyai.com/en/supabase/f-arch

> The services behind the gateway and the keys that reach them.

## Services and keys

Requests reach an **API gateway** (historically Kong) that routes them to services: **PostgREST** turns your schema into a REST API, **GoTrue** (Supabase Auth) manages users and JWTs, **Realtime** streams changes and messages, and **Storage** serves files with metadata kept in Postgres. Two kinds of key exist. The **anon** key (newer projects: **publishable** key) is safe to ship in browsers because access is still limited by Row Level Security. The **service_role** key (newer: **secret** key) bypasses RLS and must stay on servers. Key naming has been changing, so check the docs for your project.

## Where each key belongs

Environment variables split by trust level.

```bash
# .env.local (front end - safe to expose, RLS still applies)
NEXT_PUBLIC_SUPABASE_URL=https://your-project-ref.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-or-publishable-key

# server-only secrets (never prefixed for the browser, never committed)
SUPABASE_SERVICE_ROLE_KEY=your-service-role-or-secret-key
```

## The anon key is not a secret, RLS is the lock

Anyone can read the anon key from your bundle. Safety comes from Row Level Security policies, so a table without RLS is effectively public.

**Quiz:** Which key bypasses Row Level Security?

- [x] The service_role (secret) key
- [ ] The anon (publishable) key
- [ ] A user access token
- [ ] The project URL

*Answer:* The service_role (secret) key. Keep it on the server only.