code · pull · Sep 16, 2025 · Sep 16, 2025 · Sep 16, 2025 · Sep 16, 2025
diff --git a/apps/cms/next.config.mjs b/apps/cms/next.config.mjs
@@ -47,10 +47,6 @@ const nextConfig = {
     // We are already running linting via GH action, this will skip linting during production build on Vercel
     ignoreDuringBuilds: true,
   },
-  experimental: {
-    // Ensure compatibility with Turbopack and Sharp
-    serverComponentsExternalPackages: ['sharp'],
-  },
   // Configure Sharp as an external package for server-side rendering
   serverExternalPackages: ['sharp'],
 }

diff --git a/apps/cms/package.json b/apps/cms/package.json
@@ -15,7 +15,7 @@
     "lint": "cross-env NODE_OPTIONS=--no-deprecation next lint",
     "migrate": "cross-env NODE_OPTIONS=--no-deprecation tsx scripts/migrate.ts",
     "payload": "cross-env NODE_OPTIONS=--no-deprecation payload",
-    "start": "cross-env NODE_OPTIONS=--no-deprecation next start --port 3030",
+    "start": "cross-env NODE_OPTIONS=--no-deprecation next start",
     "vercel-build": "pnpm migrate && pnpm build",
     "typecheck_IGNORED": "tsc --noEmit"
   },

diff --git a/apps/cms/src/app/(payload)/api/graphql-playground/route.ts b/apps/cms/src/app/(payload)/api/graphql-playground/route.ts
diff --git a/apps/cms/src/app/(payload)/api/graphql/route.ts b/apps/cms/src/app/(payload)/api/graphql/route.ts
diff --git a/apps/cms/src/payload.config.ts b/apps/cms/src/payload.config.ts
@@ -102,7 +102,7 @@ export default buildConfig({
   // Global configuration for better performance
   globals: [],
   graphQL: {
-    disable: process.env.NODE_ENV !== 'development', // Disable GraphQL in production for better performance
+    disable: true,
   },
   // Reduce payload init overhead
   telemetry: false,

diff --git a/apps/docs/content/guides/ai/langchain.mdx b/apps/docs/content/guides/ai/langchain.mdx
@@ -76,8 +76,8 @@ $$;
 You can now search your documents using any Node.js application. This is intended to be run on a secure server route.
 
 ```js
-import { SupabaseVectorStore } from 'langchain/vectorstores/supabase'
-import { OpenAIEmbeddings } from 'langchain/embeddings/openai'
+import { SupabaseVectorStore } from '@langchain/community/vectorstores/supabase'
+import { OpenAIEmbeddings } from '@langchain/openai'
 import { createClient } from '@supabase/supabase-js'
 
 const supabaseKey = process.env.SUPABASE_SERVICE_ROLE_KEY
@@ -111,8 +111,8 @@ export const run = async () => {
 Given the above `match_documents` Postgres function, you can also pass a filter parameter to only return documents with a specific metadata field value. This filter parameter is a JSON object, and the `match_documents` function will use the Postgres JSONB Containment operator `@>` to filter documents by the metadata field values you specify. See details on the [Postgres JSONB Containment operator](https://www.postgresql.org/docs/current/datatype-json.html#JSON-CONTAINMENT) for more information.
 
 ```js
-import { SupabaseVectorStore } from 'langchain/vectorstores/supabase'
-import { OpenAIEmbeddings } from 'langchain/embeddings/openai'
+import { SupabaseVectorStore } from '@langchain/community/vectorstores/supabase'
+import { OpenAIEmbeddings } from '@langchain/openai'
 import { createClient } from '@supabase/supabase-js'
 
 // First, follow set-up instructions above
@@ -150,8 +150,8 @@ export const run = async () => {
 You can also use query builder-style filtering ([similar to how the Supabase JavaScript library works](/docs/reference/javascript/using-filters)) instead of passing an object. Note that since the filter properties will be in the metadata column, you need to use arrow operators (`->` for integer or `->>` for text) as defined in [PostgREST API documentation](https://postgrest.org/en/stable/references/api/tables_views.html?highlight=operators#json-columns) and specify the data type of the property (e.g. the column should look something like `metadata->some_int_value::int`).
 
 ```js
-import { SupabaseFilterRPCCall, SupabaseVectorStore } from 'langchain/vectorstores/supabase'
-import { OpenAIEmbeddings } from 'langchain/embeddings/openai'
+import { SupabaseFilterRPCCall, SupabaseVectorStore } from '@langchain/community/vectorstores/supabase'
+import { OpenAIEmbeddings } from '@langchain/openai'
 import { createClient } from '@supabase/supabase-js'
 
 // First, follow set-up instructions above

diff --git a/apps/docs/content/guides/auth/auth-anonymous.mdx b/apps/docs/content/guides/auth/auth-anonymous.mdx
@@ -112,7 +112,7 @@ response = supabase.auth.sign_in_anonymously()
 
 ## Convert an anonymous user to a permanent user
 
-Converting an anonymous user to a permanent user requires [linking an identity](/docs/guides/auth/auth-identity-linking#manual-linking-beta) to the user. This requires you to [enable manual linking](/dashboard/project/_/settings/auth) in your Supabase project.
+Converting an anonymous user to a permanent user requires [linking an identity](/docs/guides/auth/auth-identity-linking#manual-linking-beta) to the user. This requires you to [enable manual linking](/dashboard/project/_/auth/providers) in your Supabase project.
 
 ### Link an email / phone identity
 

diff --git a/apps/docs/content/guides/auth/auth-captcha.mdx b/apps/docs/content/guides/auth/auth-captcha.mdx
@@ -41,7 +41,7 @@ In the Settings page, look for the **Sitekey** section and copy the key.
 
 ## Enable CAPTCHA protection for your Supabase project
 
-Navigate to the **[Auth](/dashboard/project/_/settings/auth)** section of your Project Settings in the Supabase Dashboard and find the **Enable CAPTCHA protection** toggle under Settings > Authentication > Bot and Abuse Protection > Enable CAPTCHA protection.
+Navigate to the **[Auth](/dashboard/project/_/auth/protection)** section of your Project Settings in the Supabase Dashboard and find the **Enable CAPTCHA protection** toggle under Settings > Authentication > Bot and Abuse Protection > Enable CAPTCHA protection.
 
 Select your CAPTCHA provider from the dropdown, enter your CAPTCHA **Secret key**, and click **Save**.
 

diff --git a/apps/docs/content/guides/auth/auth-identity-linking.mdx b/apps/docs/content/guides/auth/auth-identity-linking.mdx
@@ -88,7 +88,7 @@ response = supabase.auth.link_identity({'provider': 'google'})
 </$Show>
 </Tabs>
 
-In the example above, the user will be redirected to Google to complete the OAuth2.0 flow. Once the OAuth2.0 flow has completed successfully, the user will be redirected back to the application and the Google identity will be linked to the user. You can enable manual linking from your project's authentication [configuration options](/dashboard/project/_/settings/auth) or by setting the environment variable `GOTRUE_SECURITY_MANUAL_LINKING_ENABLED: true` when self-hosting.
+In the example above, the user will be redirected to Google to complete the OAuth2.0 flow. Once the OAuth2.0 flow has completed successfully, the user will be redirected back to the application and the Google identity will be linked to the user. You can enable manual linking from your project's authentication [configuration options](/dashboard/project/_/auth/providers) or by setting the environment variable `GOTRUE_SECURITY_MANUAL_LINKING_ENABLED: true` when self-hosting.
 
 ## Unlink an identity
 

diff --git a/apps/docs/content/guides/auth/auth-mfa/phone.mdx b/apps/docs/content/guides/auth/auth-mfa/phone.mdx
@@ -306,7 +306,7 @@ function AuthMFA() {
 
 ### Security configuration
 
-Each code is valid for up to 5 minutes, after which a new one can be sent. Successive codes remain valid until expiry. When possible choose the longest code length acceptable to your use case, at a minimum of 6. This can be configured in the [Authentication Settings](/dashboard/project/_/settings/auth).
+Each code is valid for up to 5 minutes, after which a new one can be sent. Successive codes remain valid until expiry. When possible choose the longest code length acceptable to your use case, at a minimum of 6. This can be configured in the [Authentication Settings](/dashboard/project/_/auth/mfa).
 
 Be aware that Phone MFA is vulnerable to SIM swap attacks where an attacker will call a mobile provider and ask to port the target's phone number to a new SIM card and then use the said SIM card to intercept an MFA code. Evaluate the your application's tolerance for such an attack. You can read more about SIM swapping attacks [here](https://en.wikipedia.org/wiki/SIM_swap_scam)
 

diff --git a/apps/docs/content/guides/auth/auth-smtp.mdx b/apps/docs/content/guides/auth/auth-smtp.mdx
@@ -48,7 +48,7 @@ A non-exhaustive list of services that work with Supabase Auth is:
 - [ZeptoMail](https://www.zoho.com/zeptomail/help/smtp-home.html)
 - [Brevo](https://help.brevo.com/hc/en-us/articles/7924908994450-Send-transactional-emails-using-Brevo-SMTP)
 
-Once you've set up your account with an email sending service, head to the [Authentication settings page](/dashboard/project/_/settings/auth) to enable and configure custom SMTP.
+Once you've set up your account with an email sending service, head to the [Authentication settings page](/dashboard/project/_/auth/smtp) to enable and configure custom SMTP.
 
 You can also configure custom SMTP using the Management API:
 

diff --git a/apps/docs/content/guides/auth/general-configuration.mdx b/apps/docs/content/guides/auth/general-configuration.mdx
@@ -4,13 +4,21 @@ title: 'General configuration'
 subtitle: 'General configuration options for Supabase Auth'
 ---
 
-This section covers the [general configuration options](/dashboard/project/_/settings/auth) for Supabase Auth. If you are looking for another type of configuration, you may be interested in one of the following sections:
-
-- [Provider-specific configuration](/dashboard/project/_/auth/providers)
-- [Rate limits](/dashboard/project/_/auth/rate-limits)
-- [Email Templates](/dashboard/project/_/auth/templates)
-- [Redirect URLs](/dashboard/project/_/auth/url-configuration)
-- [Auth Hooks](/dashboard/project/_/auth/hooks)
+This section covers the [general configuration options](/dashboard/project/_/auth) for Supabase Auth. If you are looking for another type of configuration, you may be interested in one of the following sections:
+
+- [Policies](/dashboard/project/_/auth/policies) to manage Row Level Security policies for your tables.
+- [Sign In / Providers](/dashboard/project/_/auth/providers) to configure authentication providers and login methods for your users.
+- [Third Party Auth](/dashboard/project/_/auth/third-party) to use third-party authentication (TPA) systems based on JWTs to access your project.
+- [Sessions](/dashboard/project/_/auth/sessions) to configure settings for user sessions and refresh tokens.
+- [Rate limits](/dashboard/project/_/auth/rate-limits) to safeguard against bursts of incoming traffic to prevent abuse and maximize stability.
+- [Email Templates](/dashboard/project/_/auth/templates) to configure what emails your users receive.
+- [Custom SMTP](/dashboard/project/_/auth/smtp) to configure how emails are sent.
+- [Multi-Factor](/dashboard/project/_/auth/mfa) to require users to provide additional verification factors to authenticate.
+- [URL Configuration](/dashboard/project/_/auth/url-configuration) to configure site URL and redirect URLs for authentication.
+- [Attack Protection](/dashboard/project/_/auth/protection) to configure security settings to protect your project from attacks.
+- [Auth Hooks (BETA)](/dashboard/project/_/auth/auth-hooks) to use Postgres functions or HTTP endpoints to customize the behavior of Supabase Auth to meet your needs.
+- [Audit Logs (BETA)](/dashboard/project/_/auth/audit-logs) to track and monitor auth events in your project.
+- [Advanced](/dashboard/project/_/auth/advanced) to configure advanced authentication server settings.
 
 Supabase Auth provides these [general configuration options](/dashboard/project/_/settings/auth) to control user access to your application:
 

diff --git a/apps/docs/content/guides/auth/jwts.mdx b/apps/docs/content/guides/auth/jwts.mdx
@@ -165,6 +165,16 @@ val supabase = createSupabaseClient(
 </TabPanel>
 </$Show>
 
+<TabPanel id="bash" label="cURL">
+
+```bash
+curl 'https://<supabase-project>.supabase.co/rest/v1/my_table?select=id' \
+  -H "apikey: $SUPABASE_PUBLISHABLE_KEY" \
+  -H "Authorization: Bearer <your JWT here>"
+```
+
+</TabPanel>
+
 </Tabs>
 
 In the past there was a recommendation to set custom headers on the Supabase client with the `Authorization` header including your custom JWT. This is no longer recommended as it's less flexible and causes confusion when combined with a user session from Supabase Auth.

diff --git a/apps/docs/content/guides/auth/sessions.mdx b/apps/docs/content/guides/auth/sessions.mdx
@@ -55,11 +55,11 @@ There are three ways to limit the lifetime of a session:
 - Set an inactivity timeout, which terminates sessions that haven't been refreshed within the timeout duration.
 - Enforce a single-session per user, which only keeps the most recently active session.
 
-To make sure that users are required to re-authenticate periodically, you can set a positive value for the **Time-box user sessions** option in the [Auth settings](/dashboard/project/_/settings/auth) for your project.
+To make sure that users are required to re-authenticate periodically, you can set a positive value for the **Time-box user sessions** option in the [Auth settings](/dashboard/project/_/auth/sessions) for your project.
 
-To make sure that sessions expire after a period of inactivity, you can set a positive duration for the **Inactivity timeout** option in the [Auth settings](/dashboard/project/_/settings/auth).
+To make sure that sessions expire after a period of inactivity, you can set a positive duration for the **Inactivity timeout** option in the [Auth settings](/dashboard/project/_/auth/sessions).
 
-You can also enforce only one active session per user per device or browser. When this is enabled, the session from the most recent sign in will remain active, while the rest are terminated. Enable this via the _Single session per user_ option in the [Auth settings](/dashboard/project/_/settings/auth).
+You can also enforce only one active session per user per device or browser. When this is enabled, the session from the most recent sign in will remain active, while the rest are terminated. Enable this via the _Single session per user_ option in the [Auth settings](/dashboard/project/_/auth/sessions).
 
 Sessions are not proactively destroyed when you change these settings, but rather the check is enforced whenever a session is refreshed next. This can confuse developers because the actual duration of a session is the configured timeout plus the JWT expiration time. For single session per user, the effect will only be noticed at intervals of the JWT expiration time. Make sure you adjust this setting depending on your needs. We do not recommend going below 5 minutes for the JWT expiration time.
 
@@ -69,7 +69,7 @@ Otherwise sessions are progressively deleted from the database 24 hours after th
 
 ### What are recommended values for access token (JWT) expiration?
 
-Most applications should use the default expiration time of 1 hour. This can be customized in your project's [Auth settings](/dashboard/project/_/settings/auth) in the Advanced Settings section.
+Most applications should use the default expiration time of 1 hour. This can be customized in your project's [Auth settings](/dashboard/project/_/auth/sessions) in the Advanced Settings section.
 
 Setting a value over 1 hour is generally discouraged for security reasons, but it may make sense in certain situations.
 
@@ -93,7 +93,7 @@ The general rule is that a refresh token can only be used once. However, strictl
   - All clients such as browsers, mobile or desktop apps, and even some servers are inherently unreliable due to network issues. A request does not indicate that they received a response or even processed the response they received.
   - If a refresh token is revoked after being used only once, and the response wasn't received and processed by the client, when the client comes back online, it will attempt to use the refresh token that was already used. Since this might happen outside of the reuse interval, it can cause sudden and unexpected session termination.
 
-Should the reuse attempt not fall under these two exceptions, the whole session is regarded as terminated and all refresh tokens belonging to it are marked as revoked. You can disable this behavior in the Advanced Settings of the [Auth settings](/dashboard/project/_/settings/auth) page, though it is generally not recommended.
+Should the reuse attempt not fall under these two exceptions, the whole session is regarded as terminated and all refresh tokens belonging to it are marked as revoked. You can disable this behavior in the Advanced Settings of the [Auth settings](/dashboard/project/_/auth/sessions) page, though it is generally not recommended.
 
 The purpose of this mechanism is to guard against potential security issues where a refresh token could have been stolen from the user, for example by exposing it accidentally in logs that leak (like logging cookies, request bodies or URL params) or via vulnerable third-party servers. It does not guard against the case where a user's session is stolen from their device.
 

diff --git a/apps/docs/content/guides/auth/signing-keys.mdx b/apps/docs/content/guides/auth/signing-keys.mdx
@@ -176,6 +176,65 @@ supabase gen signing-key --algorithm ES256
 
 Make sure you store this private key in a secure location, as it will not be extractable from Supabase.
 
+To import the generated private key to your project, create a [new standby key](/dashboard/project/_/settings/jwt/signing-keys) from the dashboard:
+
+```json
+{
+  "kty": "EC",
+  "kid": "3a18cfe2-7226-43b0-bbb4-7c5242f2406e",
+  "d": "RDbwqThwtGP4WnvACvO_0nL0oMMSmMFSYMPosprlAog",
+  "crv": "P-256",
+  "x": "gyLVvp9dyEgylYH7nR2E2qdQ_-9Pv5i1tk7c2qZD4Nk",
+  "y": "CD9RfYOTyjR5U-PC9UDlsthRpc7vAQQQ2FTt8UsX0fY"
+}
+```
+
+Once imported, click **Rotate key** to activate your new signing key. Any JWT signed by your old key will continue to be usable until your old signing key is manually revoked.
+
+To mint a new JWT using the asymmetric signing key, you need to set the following [JWT headers](/docs/guides/auth/jwts#introduction) to match your generated private key.
+
+```json
+{
+  "alg": "ES256",
+  "kid": "3a18cfe2-7226-43b0-bbb4-7c5242f2406e",
+  "typ": "JWT"
+}
+```
+
+<Admonition type="note">
+
+The `kid` header is used to identify your public key for verification. You must use the same value when importing on platform.
+
+</Admonition>
+
+In addition, you need to provide the following custom claims as the JWT payload.
+
+```json
+{
+  "sub": "ef0493c9-3582-425f-a362-aef909588df7",
+  "role": "authenticated",
+  "exp": 1757749466
+}
+```
+
+- `sub` is an optional UUID that uniquely identifies a user you want to impersonate in `auth.users` table.
+- `role` must be set to an existing Postgres role in your database, such as `anon`, `authenticated`, or `service_role`.
+- `exp` must be set to a timestamp in the future (seconds since 1970) when this token expires. Prefer shorter-lived tokens.
+
+For simplicity, use the following CLI command to generate tokens with the desired header and payload.
+
+```bash
+supabase gen bearer-jwt --role authenticated --sub ef0493c9-3582-425f-a362-aef909588df7
+```
+
+Finally, you can use your newly minted JWT by setting the `Authorization: Bearer <JWT>` header to all [Data API requests](/docs/guides/auth/jwts#using-custom-or-third-party-jwts).
+
+<Admonition type="note">
+
+A separate `apikey` header is required to access your project's APIs. This can be a [publishable, secret or the legacy `anon` or `service_role` keys](/docs/guides/api/api-keys). Using your minted JWT is not possible in this header.
+
+</Admonition>
+
 ### Why is a 5 minute wait imposed when changing signing key states?
 
 Changing a JWT signing key's state sets off many changes inside the Supabase platform. To ensure a consistent setup, most actions that change the state of a JWT signing key are throttled for approximately 5 minutes.