mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
Tomás PozoandChris Chinchilla
4ed75886fc
## What Adds a getting-started guide for migrating an existing project from the legacy JWT-based `anon` and `service_role` keys to the new publishable (`sb_publishable_...`) and secret (`sb_secret_...`) keys. The guide walks through the migration step by step: - **Before you start** — maps legacy keys to their replacements. - **Step 1** — create the new `default` keys. - **Step 2 / 3** — swap the publishable key in client code and the secret key in backend code. - **Database Webhooks and `pg_net`** — move the key from the `Authorization: Bearer` header to the `apikey` header (the new keys aren't JWTs and are rejected on `Authorization`), with a Vault note for not inlining secrets. - **Step 4** — update Edge Functions, with two options: read the new env vars (`SUPABASE_PUBLISHABLE_KEYS` / `SUPABASE_SECRET_KEYS`) and set `verify_jwt = false`, or adopt the `@supabase/server` SDK. - **Step 5 / 6** — verify nothing uses the legacy keys, then deactivate them (reversible). - **Next steps** — clarifies that JWT signing keys are a separate, independent migration. ## Notes While writing this we found Studio issues to fix separately (the Invoke Function cURL snippet and the Database Webhooks editor both put the new keys on the `Authorization` header). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive migration guide for moving from legacy JWT-based API keys to the new publishable and secret keys with zero‑downtime steps, verification, limitations, and next steps. * Clarified API key behavior and recommended migration actions in the getting‑started docs. * Added a navigation entry linking to the new migration guide. * **Style** * Relaxed documentation lint rules to allow expected wording/phrases (e.g., "backends", "Database Webhooks"). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Chris Chinchilla <chris@chrischinchilla.com>
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the developers' guide and contributing guide.