Custom domains feature
Custom domains allow you to white-label the Supabase APIs to create a branded experience for your users. This feature is generally available but not available on self-hosted deployments.
platform
492 notes in this subject, read out of this brain and free to use. This is page 1 of 9.
Flask quickstart project setup
To set up a Python Flask project with Supabase, create a new directory, initialize a virtual environment using `python3 -m venv venv`, and activate it with `source venv/bin/activate` on Unix/Linux/Mac or `venv\Scripts\activate` on Windows.
Complete Flask + Supabase example code
import os from flask import Flask from supabase import create_client, Client from dotenv import load_dotenv load_dotenv() app = Flask(__name__) supabase: Client = create_client( os.environ.get("SUPABASE_URL"), os.environ.get("SUPABASE_PUBLISHABLE_KEY") ) @app.route('/') def index(): response = supabase.table('instruments').select("*").execute() instruments = response.data html = '<h1>Instruments</h1><ul>' for instrument in instruments: html += f'<li>{instrument["name"]}</li>' html += '</ul>' return html if __name__ == '__main__': app.run(debug=True)
Run Flask development server
Start the Flask development server by running `python app.py` in the project root. The app will be accessible at http://localhost:5000 in the browser.
Flask app with Supabase client initialization
Import Flask, create_client from supabase, Client from supabase, and load_dotenv. Load environment variables with load_dotenv(). Create the Flask app and initialize the Supabase client using create_client(os.environ.get('SUPABASE_URL'), os.environ.get('SUPABASE_PUBLISHABLE_KEY')).
Install Supabase and Flask packages
Install Flask and Supabase client library using `pip install flask supabase`. Additionally, install `python-dotenv` with `pip install python-dotenv` to load environment variables from a .env file.
Query Supabase data from Astro pages
In Astro pages (.astro files), import the createServerClient function, call it to get the supabase instance, then use await supabase.from('table_name').select() to query data server-side before rendering.
Install Supabase JS client and Node adapter for Astro
Install the supabase-js client library and @astrojs/node adapter to enable server-side rendering with npm install @supabase/supabase-js @astrojs/node.
Astro development server port
The default Astro development server runs at http://localhost:4321. Start it with npm run dev.
Astro app setup command
Create an Astro app using npm create astro@latest my-app, then cd my-app to enter the directory.
Supabase environment variables for Astro
Create a .env.local file with PUBLIC_SUPABASE_URL and PUBLIC_SUPABASE_PUBLISHABLE_KEY. These values can be obtained from the project Connect panel in the Supabase dashboard.
Astro config for SSR with Supabase
Configure astro.config.mjs with output set to 'server' and adapter set to node with mode 'standalone'. The full configuration is: import node from '@astrojs/node'; import { defineConfig } from 'astro/config'; export default defineConfig({ output: 'server', adapter: node({ mode: 'standalone' }) }).
Configure Hono environment variables
Copy .env.example to .env and update it with your Supabase project URL and publishable key from the Connect panel. These credentials are required to connect the Hono app to Supabase.
Start Hono development server
Run npm run dev to start the Hono application. The app will be available at http://localhost:5173.
supabase_flutter platform compatibility
The supabase_flutter package is compatible with web, iOS, Android, macOS, and Windows apps. Running the app on macOS requires additional configuration to set the entitlements.
Android internet permission for production
In production, Android apps need explicit internet permission to communicate with Supabase APIs. Add the following line to android/app/src/main/AndroidManifest.xml: <uses-permission android:name="android.permission.INTERNET" />
Run Flutter app command
To start a Flutter app, use the command 'flutter run'. By default, the app launches in a web browser.
Create Flutter app command
To create a new Flutter app, use the command 'flutter create my_app' where 'my_app' is the project name.
Use ViewModel for production Kotlin Android apps
In production, separate UI and data fetching logic by using a ViewModel instead of making network requests directly from UI code. This is a best practice for maintainability and testability.
Add internet permission to AndroidManifest.xml
To allow network access in an Android app, add the line <uses-permission android:name="android.permission.INTERNET" /> to the AndroidManifest.xml file under the manifest tag and outside the application tag.
RedwoodJS scaffold command for CRUD UI
Run 'yarn rw g scaffold instrument' to generate a complete CRUD user interface for a Prisma model named 'instrument'.
Create RedwoodJS app with TypeScript and yarn
Use 'yarn create redwood-app my-app --ts' to create a new RedwoodJS application with TypeScript. The yarn package manager is required. Omit the --ts flag for a JavaScript app.
Start RedwoodJS development server
Run 'yarn rw dev' to start the development server. A browser will open to the RedwoodJS Splash page. The default URL is http://localhost:8910.
Partner Catalog for extending Supabase
A curated Partner Catalog is available that offers one-click integrations, guides, and other ways to extend your Supabase project. This provides access to vetted partners who have built integrations with Supabase.
Dashboard Integrations for extensions and modules
Supabase allows you to install and manage extensions, wrappers, and Postgres Modules directly into your project through the dashboard in a couple of clicks. These can be browsed and installed from the Dashboard Integrations section.
Business viability requirement for Partner Catalog listing
Integrations are assessed on business viability. Only companies deemed to be long-term viable are listed, which requires an official business registration and bank account, meaningful revenue, or Venture Capital backing. This ensures the health of the catalog.
Service Level Agreements requirement
All Partner Catalog listings are required to have their own Terms and Conditions, Privacy Policy, and Acceptable Use Policy. The company must have resources to meet their Service Level Agreements.
Maintainability requirement for Partner Catalog
All integrations listed in the Partner Catalog must be maintained and remain functional with Supabase. Companies are assessed on their ability to remain functional over a long time horizon.
How to list an integration
To list an integration in the Partner Catalog and in the Supabase docs, apply to the Partners program at /partners/catalog#become-a-partner.
Partner Catalog definition
The Partner Catalog is Supabase's public directory of third-party integrations that extend Supabase projects. These tools cover Auth, Caching, Hosting, and Low-code categories.
Compliance requirement: no 'Supabase' in integration name
Integrations cannot use 'Supabase' in their name to avoid infringing on the Supabase brand and trademark. Since the listing appears on the Supabase domain, using 'Supabase' in the name would mislead developers into thinking the integration is an official Supabase product.
Partner Catalog vs Dashboard Integrations
The Partner Catalog is different from Dashboard Integrations. Dashboard Integrations are installed directly from a project in the Supabase Dashboard, whereas the Partner Catalog is a public directory.
Verify restored database with psql
After your local database starts up successfully from a backup, you can verify that all data is restored by connecting with psql using the command: psql 'postgresql://postgres:postgres@localhost:54322/postgres'
Start other services with restored database
If you want to use other services like Auth, Storage, and Studio dashboard together with your restored database, run 'supabase stop' followed by 'supabase start' to restart the entire local development stack.
Minimum Postgres version for local backup restore
The earliest Supabase Postgres version that supports a local restore is 15.1.0.55. If your hosted project was running on earlier versions, you will likely encounter errors during restore. When reporting errors, attach the error logs from the supabase_db_* docker container.
Download backup from dashboard for paused projects
When a paused project has exceeded its restoring time limit, you can download a backup from the dashboard. The backup file contains the database state and includes a Postgres version identifier following the 'PG:' prefix that you need to identify for restoration.
Use Migrating within Supabase guide for hosted project restore
If you want to restore your backup to a hosted Supabase project, follow the 'Migrating within Supabase' guide instead of the local restore process.
Restore downloaded backup to local development environment
To restore a downloaded backup to a local Supabase instance, first run 'supabase init' to initialize the local environment. Then create a file at supabase/.temp/postgres-version containing the backup's Postgres version number (e.g., 15.6.1.115). Finally, start the database with the command 'supabase db start --from-backup db_cluster.backup' where db_cluster.backup is the path to your backup file.
Local Postgres database not production ready
A Postgres database started with Supabase CLI is not production ready and should not be used outside of local development.
Local backup restore example command sequence
Example steps to restore a backup with Postgres version 15.6.1.115: Run 'supabase init', then execute 'echo '15.6.1.115' > supabase/.temp/postgres-version', then run 'supabase db start --from-backup db_cluster.backup'.
Advanced secrets management options
For more advanced secrets management workflows, you can use dotenvx for encrypted secrets, manage branch-specific secrets, and use encrypted configuration values directly in config.toml. See the Managing secrets for branches documentation for details.
Reference environment variables in config.toml using env()
You can reference environment variables within the config.toml file using the env() function. This detects values stored in a .env file at the root of your project directory. This is useful for storing sensitive information like API keys without checking them into version control.
config.toml file location and creation
The Supabase CLI uses a config.toml file to manage local configuration. This file is located in the supabase directory of your project. The file is automatically created when you run supabase init.
.env file should not be committed to git
Do not commit the .env file into git. Configure .gitignore to exclude the .env file to prevent sensitive information from being accidentally committed to version control.
Project directory structure for config and secrets
The typical project structure for local development includes: .env, .env.example, and supabase/config.toml at the project root. The .env file contains sensitive values, .env.example serves as a template, and config.toml is the local configuration file.
log_attributes map values are always strings
Map values in log_attributes are always strings. To compare or aggregate a numeric field, wrap it in toInt32OrZero, which returns 0 for a missing or non-numeric value.
Accessing log_attributes map fields
Structured fields live in the log_attributes map. Read a field using bracket access with the full dotted key. There are no unnesting joins required. The key keeps the full dotted path with the metadata root dropped. For example, metadata.request.cf.country in BigQuery is log_attributes['request.cf.country'] in ClickHouse. Keep the full prefix rather than shortening it.
Discover log_attributes keys from recent rows
Do not guess keys in log_attributes. Discover the keys a source sets from recent rows using: select arrayJoin(mapKeys(log_attributes)) as key, count() as n from logs where source = 'postgres_logs' group by key order by n desc limit 100;
Use narrow time range for log queries
Keep the time range tight when querying logs. Querying a very large range risks timeouts, especially for Enterprise customers with long retention, because of the extra data scanned.
Logs table columns and structure
The logs table contains the following columns: id (unique log identifier), timestamp (time the event was recorded, a DateTime64 value in UTC formatted as ISO-8601 string like 2026-06-22T09:34:06.215000), event_message (the log's message), severity_text (log level when the source sets one), source (the service the log came from), and log_attributes (structured per-source fields keyed by dotted path).
ClickHouse logs table structure
The Logs Explorer runs on ClickHouse. Every log line from every source is one row in a single logs table. The table contains a source column to tag which service the log came from, a log_attributes map containing structured fields, and an event_message column containing the raw line. Filter by source to scope a query to one service.
Timestamp is UTC and ISO-8601 formatted
The timestamp column is a DateTime64 value in UTC, formatted as an ISO-8601 string like 2026-06-22T09:34:06.215000. You can order and compare it directly without needing conversion functions. In the Logs Explorer the selected time range is applied automatically, so filtering on timestamp by hand is rarely needed.
Regex case-insensitive matching
Use (?i) in regex patterns to ignore capitalization for all proceeding characters. For example: match(event_message, '(?i)COnnecTion'). For a plain case-insensitive substring match, ilike is simpler: event_message ilike '%connection%'.
SQL logical operators with regex
and, or, and not are native SQL terms and can be used with regular expressions to filter results. For example: where source = 'postgres_logs' and ((match(event_message, 'connection') and match(event_message, 'host')) or not match(event_message, 'received')).
Wildcard operator not supported in log queries
The logs query surface rejects select * and count(*). List the columns you need, and use count() without arguments for row counts.
Select only needed fields in log queries
Select only the specific keys you need in log queries. Selecting the whole log_attributes map or every column reads far more data than necessary and slows the query down. For example, select timestamp, log_attributes['request.method'] as method instead of select timestamp, log_attributes.
ClickHouse match function for regex filtering
Use the ClickHouse match function for regular expressions in log filtering. The match function checks whether a pattern is present in a column. Syntax: match(column, 'pattern').
Example: Query edge logs by method, path, and status
Example query to retrieve request method, path, and status from edge logs: ```sql select log_attributes['request.method'] as method, log_attributes['request.path'] as path, log_attributes['response.status_code'] as status from logs where source = 'edge_logs' limit 100; ```
Regex anchors for string start and end
In ClickHouse regex patterns, use ^ to match only values at the start of a string and $ to match only values at the end of a string. For example: match(event_message, '^connection') or match(event_message, 'port=12345$').
Regex wildcard patterns
In ClickHouse regex, . matches any single character and .* matches any sequence of characters. For example: match(event_message, 'hello.*world').