[pull] master from supabase:master

apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts

@@ -3062,7 +3062,7 @@ export const telemetry: NavMenuConstant = {
           url: '/guides/monitoring-and-debugging/sentry-monitoring' as `/${string}`,
         },
         {
-          name: 'Tracing with the JS SDK',
+          name: 'Tracing with the client SDKs',
           url: '/guides/monitoring-and-debugging/client-side-tracing' as `/${string}`,
         },
       ],

apps/docs/components/RealtimeLimitsEstimator/RealtimeLimitsEstimator.tsx

@@ -57,7 +57,9 @@ export default function RealtimeLimitsEstimater({}) {
 
   return (
     <div>
-      <h4>Set your expected parameters</h4>
+      <span className="block font-heading font-semibold text-lg mt-9 mb-[18px] text-foreground">
+        Set your expected parameters
+      </span>
       <div className="grid mb-8 gap-y-8 gap-x-8 grid-cols-2 xl:grid-cols-4">
         <div>
           <Label htmlFor="computeAddOn">Compute:</Label>
@@ -107,7 +109,9 @@ export default function RealtimeLimitsEstimater({}) {
 
       {limits && (
         <div className="mt-8">
-          <h4>Current maximum possible throughput</h4>
+          <span className="block font-heading font-semibold text-lg mt-9 mb-[18px] text-foreground">
+            Current maximum possible throughput
+          </span>
 
           <table className="table-auto">
             <thead>
@@ -158,7 +162,9 @@ export default function RealtimeLimitsEstimater({}) {
               .filter((v, i, a) => a.indexOf(v) === i)
               .map((computeAddOn) => (
                 <div>
-                  <h4>{COMPUTE_LABELS[computeAddOn]}</h4>
+                  <span className="block font-heading font-semibold text-lg mt-9 mb-[18px] text-foreground">
+                    {COMPUTE_LABELS[computeAddOn]}
+                  </span>
                   <table className="table-auto">
                     <thead>
                       <tr>

apps/docs/content/_partials/social_provider_setup.mdx

@@ -5,9 +5,7 @@ The next step requires a callback URL, which looks like this: `https://<project-
 - Click on [`Sign In / Providers`](/dashboard/project/_/auth/providers) under the Configuration section
 - Click on **{{ .provider }}** from the accordion list to expand and you'll find your **Callback URL**, you can click `Copy` to copy it to the clipboard
 
-<Admonition type="note">
-
-#### Local development
+### Local development
 
 When testing OAuth locally with the Supabase CLI, ensure your OAuth provider
 is configured with the local Supabase Auth callback URL:
@@ -19,5 +17,3 @@ If this callback URL is missing or misconfigured, OAuth sign-in may fail or not
 See the [local development docs](/docs/guides/local-development) for more details.
 
 For testing OAuth locally with the Supabase CLI see the [local development docs](/docs/guides/local-development).
-
-</Admonition>

apps/docs/content/guides/auth/quickstarts/astrojs.mdx

@@ -5,6 +5,8 @@ breadcrumb: 'Auth Quickstarts'
 hideToc: true
 ---
 
+## Quickstart
+
 <StepHikeCompact>
 
   <StepHikeCompact.Step step={1}>

apps/docs/content/guides/auth/quickstarts/nextjs.mdx

@@ -5,6 +5,8 @@ breadcrumb: 'Auth Quickstarts'
 hideToc: true
 ---
 
+## Quickstart
+
 <StepHikeCompact>
 
   <StepHikeCompact.Step step={1}>

apps/docs/content/guides/auth/quickstarts/react-native.mdx

@@ -5,6 +5,8 @@ breadcrumb: 'Auth Quickstarts'
 hideToc: true
 ---
 
+## Quickstart
+
 <StepHikeCompact>
 
   <StepHikeCompact.Step step={1}>

apps/docs/content/guides/auth/quickstarts/react.mdx

@@ -5,6 +5,8 @@ breadcrumb: 'Auth Quickstarts'
 hideToc: true
 ---
 
+## Quickstart
+
 <StepHikeCompact>
 
   <StepHikeCompact.Step step={1}>

apps/docs/content/guides/database/functions.mdx

@@ -164,7 +164,7 @@ For example, if we had a database with some Star Wars data inside:
 >
 <TabPanel id="data" label="Data">
 
-<h4>Planets</h4>
+### Planets
 
 ```
 | id  | name     |
@@ -174,7 +174,7 @@ For example, if we had a database with some Star Wars data inside:
 | 3   | Kashyyyk |
 ```
 
-<h4>People</h4>
+### People
 
 ```
 | id  | name             | planet_id |

apps/docs/content/guides/integrations/vercel-marketplace.mdx

@@ -23,7 +23,7 @@ Vercel Marketplace is currently in Public Alpha. If you encounter any issues or
 ### Via template
 
 <div className="bg-surface-100 py-4 px-5 border rounded-md not-prose">
-  <h5 className="text-foreground">Deploy a Next.js app with Supabase Vercel Storage now</h5>
+  <h4 className="text-foreground">Deploy a Next.js app with Supabase Vercel Storage now</h4>
   <p className="text-foreground-light mb-3">Uses the Next.js Supabase Starter Template</p>
   <a href="https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Fvercel%2Fnext.js%2Ftree%2Fcanary%2Fexamples%2Fhello-world">
     <img src="https://vercel.com/button" alt="Deploy with Vercel" />

apps/docs/content/guides/monitoring-and-debugging/client-side-tracing.mdx

@@ -1,12 +1,22 @@
 ---
 id: 'client-side-tracing'
-title: 'Tracing with the JS SDK'
-description: 'Propagate W3C trace context from the Supabase JS SDK through Supabase services'
+title: 'Client-side tracing'
+description: 'Propagate W3C trace context from the Supabase JS, Swift, and Dart SDKs through Supabase services'
 ---
 
-The Supabase JS SDK can attach [W3C Trace Context](https://www.w3.org/TR/trace-context/) headers (`traceparent`, `tracestate`, `baggage`) to outgoing requests. The resulting `trace_id` flows through Supabase services and appears in API Gateway and Edge Function logs, so you can correlate client-side spans with the server-side logs they produced — end-to-end, across the network boundary.
+The Supabase JS, Swift, and Dart SDKs can attach [W3C Trace Context](https://www.w3.org/TR/trace-context/) headers (`traceparent`, `tracestate`, `baggage`) to outgoing requests. The resulting `trace_id` flows through Supabase services and appears in API Gateway and Edge Function logs, so you can correlate client-side spans with the server-side logs they produced — end-to-end, across the network boundary.
 
-Because the headers follow the W3C standard, any compliant tracing SDK (OpenTelemetry, Sentry, Datadog, Honeycomb, etc.) can pick up the trace on the server side, including in self-hosted collectors.
+Because the headers follow the W3C standard, any compliant tracing SDK (such as OpenTelemetry, Sentry, Datadog, or Honeycomb) can pick up the trace on the server side, including in self-hosted collectors.
+
+<Tabs
+  scrollable
+  size="small"
+  type="underlined"
+  defaultActiveId="js"
+  queryGroup="language"
+>
+
+<TabPanel id="js" label="JavaScript">
 
 ## Requirements
 
@@ -34,7 +44,7 @@ Trace propagation isn't available through the CDN (UMD) build — there's no way
 
 The SDK reads from whatever `TracerProvider` you register globally — it doesn't configure one for you. If you haven't instrumented your app yet, follow the [OpenTelemetry JavaScript getting started guide](https://opentelemetry.io/docs/languages/js/getting-started/) to install an SDK (`@opentelemetry/sdk-trace-node` for Node, `@opentelemetry/sdk-trace-web` for browsers) and an exporter for your backend (OTLP, Jaeger, Zipkin, or a vendor-specific one).
 
-The Supabase SDK only takes care of propagating the trace context that's already active when a request is made.
+The Supabase SDK only propagates the trace context that's already active when a request is made.
 
 ## Enable trace propagation
 
@@ -84,18 +94,9 @@ const supabase = createClient(SUPABASE_URL, SUPABASE_KEY, {
 | `enabled`                 | `boolean` | `false` | Enable trace propagation.                                           |
 | `respectSamplingDecision` | `boolean` | `true`  | If `true`, skip propagation when the upstream trace is not sampled. |
 
-## Correlating with Supabase logs
-
-Once trace context is flowing through, the `trace_id` appears in:
-
-- **API Gateway logs** — every request to PostgREST, Auth, Storage, and Realtime
-- **Edge Function logs** — invocations and any structured logs emitted from within the function
-
-If you forward Supabase logs to a third-party backend via [Log Drains](/docs/guides/monitoring-and-debugging/log-drains), you can join Supabase logs to your own client and server traces using the shared `trace_id`. This is especially useful for self-hosted setups where you already operate your own OpenTelemetry collector — Supabase logs become first-class citizens in your existing tracing UI.
-
 ## Using a vendor tracing SDK
 
-Many tracing SDKs are built on top of OpenTelemetry. They work with this guide as long as a W3C-compliant propagator is registered — but propagator behavior varies. Some vendor SDKs inject only their proprietary headers by default and need extra configuration to also emit the standard `traceparent` header. Check your vendor's OTel integration docs for the exact setup.
+Many tracing SDKs are built on top of OpenTelemetry. They work with this guide as long as a W3C-compliant propagator is registered. Some vendor SDKs inject only their proprietary headers by default and need extra configuration to also emit the standard `traceparent` header. Check your vendor's OTel integration docs for the exact setup.
 
 ## Troubleshooting
 
@@ -104,7 +105,116 @@ The SDK never throws when it can't propagate, which keeps it safe to enable but
 - **The tracing runtime isn't loaded** (version `2.112.0` and later). `tracePropagation` is enabled but your entry point never imports `@supabase/supabase-js/tracing`. The SDK logs a one-time console warning and sends requests without trace headers — look for that warning in your console.
 - **No active span at request time.** The SDK reads the _current_ context. If `supabase.from(...)` is called outside `tracer.startActiveSpan(...)` (or equivalent), there's nothing to propagate. Wrap the call in a span or use OpenTelemetry's automatic instrumentation.
 - **`@opentelemetry/api` is not installed** in the app making the request. On `2.112.0` and later the tracing subpath imports it directly, so a missing package surfaces as a module resolution error. On `2.106.0`–`2.111.x` it's loaded dynamically and the SDK silently no-ops.
-- **No `TracerProvider` registered.** `@opentelemetry/api` defaults to a noop provider that produces non-recorded spans. Make sure your app calls `provider.register()` (or your vendor SDK's equivalent) before making requests.
+- **No `TracerProvider` registered.** `@opentelemetry/api` defaults to a noop provider that produces non-recorded spans. Ensure your app calls `provider.register()` (or your vendor SDK's equivalent) before making requests.
 - **The upstream trace is not sampled.** By default the SDK respects upstream sampling decisions. Set `respectSamplingDecision: false` to propagate every request regardless of sampling.
 - **You're calling a non-Supabase host through a custom `fetch`.** Trace headers are only attached to Supabase domains (`*.supabase.co`, `*.supabase.in`, `localhost`).
 - **You're using the CDN (UMD) build.** Trace propagation isn't available there — the tracing runtime can't be loaded from a script tag.
+
+</TabPanel>
+
+<TabPanel id="swift" label="Swift">
+
+Requires `supabase-swift` `2.51.0` or later and `swift-tools-version: 6.1` or later (SwiftPM trait support).
+
+1. **Add the `OpenTelemetry` trait** to your dependency declaration in `Package.swift`:
+
+   ```swift
+   // Package.swift
+   .package(
+     url: "https://github.com/supabase/supabase-swift.git",
+     from: "2.51.0",
+     traits: ["OpenTelemetry"]
+   )
+   ```
+
+   No changes to `SupabaseClient` are required. After enabling the trait, the active OpenTelemetry span's trace context is automatically injected as a `traceparent` header on every outgoing request across PostgREST, Storage, Auth, Functions, and Realtime. When there is no active span, the header is not added.
+
+2. **Register a `TracerProvider`** at app start. The SDK reads from whatever provider you register globally:
+
+   ```swift
+   import Supabase
+   import OpenTelemetryApi
+   import OpenTelemetrySdk
+
+   let exporter = /* your OTLP / Jaeger / Zipkin exporter */
+   let spanProcessor = SimpleSpanProcessor(spanExporter: exporter)
+   let provider = TracerProviderBuilder()
+     .add(spanProcessor: spanProcessor)
+     .build()
+   OpenTelemetry.registerTracerProvider(tracerProvider: provider)
+   ```
+
+3. **Create your `SupabaseClient`**. Any active span is now propagated automatically:
+
+   ```swift
+   let supabase = SupabaseClient(
+     supabaseURL: URL(string: "https://xyzcompany.supabase.co")!,
+     supabaseKey: "your-publishable-key"
+   )
+   ```
+
+</TabPanel>
+
+<TabPanel id="dart" label="Dart">
+
+Requires `supabase` `2.x` or later (Flutter or Dart-only).
+
+1. **Implement a `traceContextProvider`** that returns the current `TraceContext` from your tracing library. Return `null` when there is no active span.
+
+2. **Pass `TracePropagationOptions`** when creating the client:
+
+   ```dart
+   import 'package:supabase/supabase.dart';
+
+   final supabase = SupabaseClient(
+     'https://xyzcompany.supabase.co',
+     'your-publishable-key',
+     tracePropagationOptions: TracePropagationOptions(
+       enabled: true,
+       traceContextProvider: () {
+         final span = YourTracer.activeSpan;
+         if (span == null) return null;
+         return TraceContext(
+           traceparent: span.traceparent,
+           tracestate: span.tracestate,
+         );
+       },
+     ),
+   );
+   ```
+
+   For `supabase_flutter`, pass the same option through `Supabase.initialize`:
+
+   ```dart
+   await Supabase.initialize(
+     url: 'https://xyzcompany.supabase.co',
+     anonKey: 'your-publishable-key',
+     tracePropagationOptions: TracePropagationOptions(
+       enabled: true,
+       traceContextProvider: () => yourTraceContextProvider(),
+     ),
+   );
+   ```
+
+## Options
+
+| Option                    | Type                    | Default | Description                                                                                                                                                                       |
+| ------------------------- | ----------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `enabled`                 | `bool`                  | `false` | Enable trace propagation.                                                                                                                                                         |
+| `respectSamplingDecision` | `bool`                  | `true`  | When `true`, skips propagation if the upstream trace is not sampled. Set to `false` to always attach a `trace_id` — useful for log correlation even when traces are not exported. |
+| `traceContextProvider`    | `TraceContextProvider?` | `null`  | Callback returning the current `TraceContext`. Return `null` when there is no active span.                                                                                        |
+
+Headers are only injected on requests targeting Supabase hosts (`*.supabase.co`, `*.supabase.in`, your project host, and loopback addresses for local development). Third-party hosts never receive trace headers.
+
+</TabPanel>
+
+</Tabs>
+
+## Correlating with Supabase logs
+
+After trace context is flowing through, the `trace_id` appears in:
+
+- **API Gateway logs** — every request to PostgREST, Auth, Storage, and Realtime
+- **Edge Function logs** — invocations and any structured logs emitted from within the function
+
+If you forward Supabase logs to a third-party backend via [Log Drains](/docs/guides/monitoring-and-debugging/log-drains), you can join Supabase logs to your own client and server traces using the shared `trace_id`. This is especially useful for self-hosted setups where you already operate your own OpenTelemetry collector — Supabase logs become first-class citizens in your existing tracing UI.

apps/docs/content/guides/self-hosting/docker.mdx

@@ -80,6 +80,7 @@ The script supports Linux only (Debian/Ubuntu and RHEL/CentOS/Fedora) and will:
 - Install prerequisites (`git`, `openssl`, `jq`) and Docker Engine if not already present
 - Sparse-clone the `docker/` directory from the main Supabase [repository](https://github.com/supabase/supabase/)
 - Create a project directory (`supabase-project` by default) and copy the configuration files into it
+- Record the installed release version in `.supabase-version` for future `update.sh` upgrades
 - Prompt for the main URLs (`SUPABASE_PUBLIC_URL`, `API_EXTERNAL_URL`, `SITE_URL`, `PROXY_DOMAIN`) and write them to `.env`
 - Generate all secrets, including a random `DASHBOARD_PASSWORD`, and the asymmetric JWT signing key pair (runs `generate-keys.sh` and `add-new-auth-keys.sh`, and enables the matching entries in `docker-compose.yml`)
 - Pull the Docker images
@@ -105,7 +106,7 @@ Not on Linux, or want to do it manually? See [Manual installation](#manual-insta
 
 ### Manual installation
 
-This path gets the Docker Compose configuration onto your server; you'll configure secrets, keys, and URLs in the [next section](#configuring-and-securing-supabase).
+This path gets the Docker Compose configuration onto your server, pinned to a specific tag. You'll set up secrets, keys, and URLs in the [next section](#configuring-and-securing-supabase). For a newer release, use the [latest tag](https://github.com/supabase/supabase/tags).
 
 <Tabs
 scrollable
@@ -121,7 +122,7 @@ A shallow clone of the full Supabase repository. Works on any OS with `git` inst
 
 ```sh
 # Get the code
-git clone --depth 1 https://github.com/supabase/supabase
+git clone --depth 1 --branch self-hosted/v0.7.1 https://github.com/supabase/supabase
 
 # Make your new supabase project directory
 mkdir supabase-project
@@ -137,6 +138,9 @@ cp -rf supabase/docker/. supabase-project
 # Switch to the project directory and create a .env from the example
 cd supabase-project && cp .env.example .env
 
+# Record the base version so update.sh can upgrade this install later
+printf 'ref=self-hosted/v0.7.1\n' > .supabase-version
+
 # Pull the latest images
 docker compose pull
 ```
@@ -149,7 +153,7 @@ Only downloads the `docker/` directory from the repository, saving bandwidth and
 
 ```sh
 # Get the code using git sparse checkout
-git clone --filter=blob:none --no-checkout --depth=1 --quiet https://github.com/supabase/supabase
+git clone --filter=blob:none --no-checkout --depth=1 --quiet --branch self-hosted/v0.7.1 https://github.com/supabase/supabase
 cd supabase
 git sparse-checkout init --cone
 git sparse-checkout set docker
@@ -170,6 +174,9 @@ cp -rf supabase/docker/. supabase-project
 # Switch to the project directory and create a .env from the example
 cd supabase-project && cp .env.example .env
 
+# Record the base version so update.sh can upgrade this install later
+printf 'ref=self-hosted/v0.7.1\n' > .supabase-version
+
 # Pull the latest images
 docker compose pull
 ```

apps/docs/public/humans.txt

@@ -104,6 +104,7 @@ Fady A
 Fatuma Abdullahi
 Felipe Stival
 Ferhat Elmas
+Filipe Cabaco
 Firas El Rachidi
 Francesco Sansalvadore
 Gabriel Claudino
@@ -271,6 +272,7 @@ Shaii O
 Shane Adams
 Shane E
 Shaun Newman
+Shardul Borhade
 Shreekar Shetty
 Sreyas Udayavarman
 Stephanie Jackson (stejacks)
@@ -294,6 +296,7 @@ Tim Frietas
 Tim Palmer
 Timothy Lim
 Tina Ha
+Tobias Pfeiffer
 Tom Ashley
 Tom G
 Tomás Pozo

apps/docs/scripts/generate-dart-reference.ts

@@ -58,10 +58,10 @@ const OUT_PATH = join(VERSION_DIR, 'supabase_flutter.json')
 const HEADER_IDS = new Set([
   'auth-api',
   'auth-mfa-api',
+  'oauth-server-api',
   'passkey-api',
   'admin-api',
   'admin-passkey-api',
-  'oauth-server-api',
   'admin-custom-providers-api',
   'functions-api',
   'database-api',