Supabase CLI

初始化 Supabase 本地开发的配置。

在当前工作目录中创建 supabase/config.toml 文件。此配置特定于每个本地项目。

您可以通过指定 SUPABASE_WORKDIR 环境变量或 --workdir 标志来覆盖目录路径。

除了 config.toml 之外，supabase 目录还可以包含其他 Supabase 对象，例如 migrations、functions、tests 等。

通过使用您的个人访问令牌登录，将 Supabase CLI 连接到您的 Supabase 帐户。

您的访问令牌安全地存储在原生凭据存储中。如果原生凭据存储不可用，它将写入 ~/.supabase/access-token 的纯文本文件。

如果不需要此行为，例如在 CI 环境中，您可以通过在其他命令中指定 SUPABASE_ACCESS_TOKEN 环境变量来跳过登录。

Supabase CLI 使用存储的令牌访问项目、函数、秘密等管理 API。

将您的本地开发项目链接到托管的 Supabase 项目。

PostgREST 配置从 Supabase 平台获取，并根据您的本地配置文件进行验证。

可选地，如果您提供密码，可以验证数据库设置。您的数据库密码（如果可用）将保存在原生凭据存储中。

如果您不想被提示输入数据库密码，例如在 CI 环境中，您可以通过 SUPABASE_DB_PASSWORD 环境变量明确指定它。

某些命令（如 db dump、db push 和 db pull）要求您的项目首先被链接。

启动 Supabase 本地开发堆栈。

需要通过运行 supabase init 在当前工作目录中创建 supabase/config.toml。

默认情况下，所有服务容器都会启动。您可以通过传入 -x 标志来排除不需要的容器。要排除多个容器，可以传入逗号分隔的字符串，例如 -x gotrue,imgproxy，或者多次指定 -x 标志。

建议至少拥有 7GB RAM 以启动所有服务。

会自动添加健康检查以验证已启动的容器。使用 --ignore-health-check 标志忽略这些错误。

停止 Supabase 本地开发堆栈。

需要通过运行 supabase init 在当前工作目录中创建 supabase/config.toml。

所有 Docker 资源在重启后都会保留。使用 --no-backup 标志在重启之间重置本地开发数据。

使用 --all 标志停止机器上所有本地 Supabase 项目实例。与 --no-backup 一起使用时请务必小心，因为它会删除所有 Supabase 本地项目数据。

显示 Supabase 本地开发堆栈的状态。

需要通过运行 supabase start 或 supabase db start 启动本地开发堆栈。

您可以通过指定 -o env 标志导出连接参数以在本地初始化 supabase-js。支持的参数包括 JWT_SECRET、ANON_KEY 和 SERVICE_ROLE_KEY。

对本地数据库执行 pgTAP 测试。

需要通过运行 supabase start 启动本地开发堆栈。

在容器中运行 pg_prove，并从 supabase/tests 目录挂载单元测试文件。测试文件可以以 .sql 或 .pg 扩展名结尾。

由于每个测试都封装在自己的事务中，因此无论成功或失败，它都会单独回滚。

根据您的 Postgres 数据库模式自动生成类型定义。

此命令连接到您的数据库（本地或远程），并生成与您的数据库表、视图和存储过程匹配的类型化定义。默认情况下，它生成 TypeScript 定义，但也支持 Go 和 Swift。

生成的类型在您使用代码中的数据库时提供类型安全和自动补全，有助于防止运行时错误并改善开发人员体验。

这些类型遵守数据库模式中定义的关系、约束和自定义类型。

安全地生成私有 JWT 签名密钥，用于 CLI 或导入到仪表板。

支持的算法：ES256 - 带 P-256 曲线和 SHA-256 的 ECDSA（推荐）RS256 - 带 SHA-256 的 RSA

从远程数据库拉取模式更改。将在 supabase/migrations 目录下创建一个新的迁移文件。

需要通过运行 supabase link 将您的本地项目链接到远程数据库。对于自托管数据库，您可以使用 --db-url 标志传入连接参数。

请注意，此命令需要 Docker Desktop（或正在运行的 Docker 守护程序），因为它会启动一个本地 Postgres 容器来对比您的远程模式。

可选地，可以在迁移历史表中插入新行以反映远程数据库的当前状态。

如果迁移历史表中没有条目，则将使用 pg_dump 捕获您已创建的远程模式的所有内容。否则，此命令将仅对比远程数据库的模式更改，类似于运行 db diff --linked。

将所有本地迁移推送到远程数据库。

需要通过运行 supabase link 将您的本地项目链接到远程数据库。对于自托管数据库，您可以使用 --db-url 标志传入连接参数。

首次运行此命令时，将在 supabase_migrations.schema_migrations 下创建一个迁移历史表。成功应用迁移后，将在迁移历史表中插入一个新行，以时间戳作为其唯一 ID。后续的推送将跳过已应用的迁移。

如果您需要修改迁移历史表，例如删除现有条目或插入新条目而不实际运行迁移，请使用 migration repair 命令。

使用 --dry-run 标志在应用之前查看更改列表。

将本地数据库重置为干净状态。

需要通过运行 supabase start 启动本地开发堆栈。

重新创建本地 Postgres 容器并应用在 supabase/migrations 目录中找到的所有本地迁移。如果测试数据在 supabase/seed.sql 中定义，则将在运行迁移后进行填充。本地开发期间进行的任何其他数据或模式更改都将被丢弃。

当运行 db reset 与 --linked 或 --db-url 标志时，会执行一个 SQL 脚本来识别并删除远程数据库中所有用户创建的实体。由于 Postgres 角色是集群级实体，因此通过仪表板或 supabase/roles.sql 创建的任何自定义角色都不会被远程重置删除。

从远程数据库转储内容。

需要通过运行 supabase link 将您的本地项目链接到远程数据库。对于自托管数据库，您可以使用 --db-url 标志传入连接参数。

在容器中运行 pg_dump，并带有附加标志以排除 Supabase 管理的模式。忽略的模式包括 auth、storage 以及由扩展创建的模式。

默认转储不包含任何数据或自定义角色。要明确转储这些内容，请指定 --data-only 和 --role-only 标志。

对比对本地或远程数据库所做的模式更改。

当与本地数据库对比时，需要本地开发堆栈正在运行。要与远程或自托管数据库对比，请分别指定 --linked 或 --db-url 标志。

在容器中运行 djrobstep/migra，以比较目标数据库和影子数据库之间的模式差异。影子数据库是通过在单独的容器中应用本地 supabase/migrations 目录中的迁移来创建的。输出默认写入 stdout。为方便起见，您还可以通过传入 -f 标志将模式差异保存为新的迁移文件。

默认情况下，目标数据库中的所有模式都会被对比。使用 --schema public,extensions 标志将对比限制为模式的子集。

虽然 diff 命令能够捕获大多数模式更改，但在某些情况下已知会失败。目前，如果您的模式包含以下内容，则可能会发生这种情况：

• 发布更改
• 存储桶更改
• 具有 security_invoker 属性的视图

检查本地数据库以查找模式错误。

当针对本地数据库进行 linting 时，需要本地开发堆栈正在运行。要针对远程或自托管数据库进行 linting，请分别指定 --linked 或 --db-url 标志。

在本地 Postgres 容器中运行 plpgsql_check 扩展，以检查所有模式中的错误。默认的 lint 级别是 warning，可以通过 --level 标志提高到 error。

要仅针对特定模式进行 linting，请传入 --schema 标志。

--fail-on 标志可用于控制命令何时以非零状态码退出。可能的值是

• none（默认）：始终以零状态码退出，无论 lint 结果如何。
• warning：如果发现任何警告或错误，则以非零状态码退出。
• error：仅在发现错误时以非零状态码退出。

此标志在 CI/CD 管道中特别有用，您希望根据某些 lint 条件使构建失败。

在本地创建新的迁移文件。

如果 workdir 中不存在 supabase/migrations 目录，则会创建它。所有模式迁移文件都必须在此目录中创建，遵循模式 <timestamp>_<name>.sql。

来自其他命令（如 db diff）的输出可以通过 stdin 管道传输到 migration new <name>。

列出本地和远程数据库中的迁移历史。

需要通过运行 supabase link 将您的本地项目链接到远程数据库。对于自托管数据库，您可以使用 --db-url 标志传入连接参数。

请注意，URL 字符串必须根据 RFC 3986 进行转义。

本地迁移存储在 supabase/migrations 目录中，而远程迁移则在 supabase_migrations.schema_migrations 表中跟踪。仅比较时间戳以识别任何差异。

如果本地和远程迁移历史之间存在差异，您可以使用 migration repair 命令解决它们。

修复远程迁移历史表。

需要通过运行 supabase link 将您的本地项目链接到远程数据库。

如果您的本地和远程迁移历史不同步，您可以通过将特定迁移标记为 --status applied 或 --status reverted 来修复远程历史。标记为 reverted 将从迁移历史表中删除现有记录，而标记为 applied 将插入新记录。

例如，您的迁移历史可能如下表所示，其中本地或远程缺少条目。

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
                   │ 20230103054303 │ 2023-01-03 05:43:03
   20230103054315  │                │ 2023-01-03 05:43:15

要将迁移历史重置为干净状态，请首先删除您的本地迁移文件。

$ rm supabase/migrations/20230103054315_remote_commit.sql

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
                   │ 20230103054303 │ 2023-01-03 05:43:03

然后将远程迁移 20230103054303 标记为已恢复。

$ supabase migration repair 20230103054303 --status reverted
Connecting to remote database...
Repaired migration history: [20220810154537] => reverted
Finished supabase migration repair.

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────

现在您可以再次运行 db pull 以将远程模式转储为本地迁移文件。

$ supabase db pull
Connecting to remote database...
Schema written to supabase/migrations/20240414044403_remote_schema.sql
Update remote migration history table? [Y/n]
Repaired migration history: [20240414044403] => applied
Finished supabase db pull.

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
    20240414044403 │ 20240414044403 │ 2024-04-14 04:44:03

将本地模式迁移合并到单个迁移文件。

合并后的迁移等同于应用现有迁移文件后本地数据库的仅模式转储。当您希望从迁移历史中删除同一模式的重复修改时，这特别有用。

然而，一个限制是数据操作语句（例如插入、更新或删除）在合并后的迁移中被省略。您必须在新迁移文件中手动添加它们。这包括 cron 作业、存储桶以及 vault 中任何加密的秘密。

默认情况下，最新的 <timestamp>_<name>.sql 文件将更新为包含合并后的迁移。您可以使用 --version <timestamp> 标志覆盖目标版本。

如果您的 supabase/migrations 目录为空，运行 supabase squash 将不执行任何操作。

此命令显示表“膨胀”的估计值 - 由于 Postgres 的 MVCC，当数据更新或删除时，会创建新行，旧行将变为不可见并标记为“死元组”。通常，autovaccum 进程会异步清理死元组。有时 autovaccum 无法足够快地工作以减少或防止表膨胀。高膨胀会减慢查询速度，导致过多的 IOPS 并浪费数据库空间。

应调查膨胀率高的表，以查看 vacuuming 是否不够快或是否存在其他问题。

    TYPE  │ SCHEMA NAME │        OBJECT NAME         │ BLOAT │ WASTE
  ────────┼─────────────┼────────────────────────────┼───────┼─────────────
    table │ public      │ very_bloated_table         │  41.0 │ 700 MB
    table │ public      │ my_table                   │   4.0 │ 76 MB
    table │ public      │ happy_table                │   1.0 │ 1472 kB
    index │ public      │ happy_table::my_nice_index │   0.7 │ 880 kB

此命令显示当前持有锁并阻塞的语句，以及正在被阻塞的语句。这可以与 inspect db locks 结合使用，以确定需要终止哪些语句才能解决锁争用。

    BLOCKED PID │ BLOCKING STATEMENT           │ BLOCKING DURATION │ BLOCKING PID │ BLOCKED STATEMENT                                                                      │ BLOCKED DURATION
  ──────────────┼──────────────────────────────┼───────────────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────────────┼───────────────────
    253         │ select count(*) from mytable │ 00:00:03.838314   │        13495 │ UPDATE "mytable" SET "updated_at" = '2023─08─03 14:07:04.746688' WHERE "id" = 83719341 │ 00:00:03.821826

此命令与 supabase inspect db outliers 命令非常相似，但按语句被调用的次数排序。

您可以使用此信息查看哪些查询被调用最频繁，这些查询可能成为优化的良好候选者。

                        QUERY                      │ TOTAL EXECUTION TIME │ PROPORTION OF TOTAL EXEC TIME │ NUMBER CALLS │  SYNC IO TIME
  ─────────────────────────────────────────────────┼──────────────────────┼───────────────────────────────┼──────────────┼──────────────────
    SELECT * FROM users WHERE id = $1              │ 14:50:11.828939      │ 89.8%                         │  183,389,757 │ 00:00:00.002018
    SELECT * FROM user_events                      │ 01:20:23.466633      │ 1.4%                          │       78,325 │ 00:00:00
    INSERT INTO users (email, name) VALUES ($1, $2)│ 00:40:11.616882      │ 0.8%                          │       54,003 │ 00:00:00.000322

此命令显示已对关系取出排他锁的查询。排他锁通常会阻止在该关系上进行其他操作，并可能导致“挂起”的查询等待授予锁。

如果您看到一个查询长时间挂起或导致阻塞问题，您可以考虑通过连接到数据库并运行 SELECT pg_cancel_backend(PID); 来终止查询。如果查询仍然没有停止，您可以通过运行 SELECT pg_terminate_backend(PID); 强制停止。

     PID   │ RELNAME │ TRANSACTION ID │ GRANTED │                  QUERY                  │   AGE
  ─────────┼─────────┼────────────────┼─────────┼─────────────────────────────────────────┼───────────
    328112 │ null    │              0 │ t       │ SELECT * FROM logs;                     │ 00:04:20

此命令显示当前正在运行的查询，这些查询已运行超过 5 分钟，按持续时间降序排列。长时间运行的查询可能是多个问题的根源，例如阻止 DDL 语句完成或 vacuum 无法更新 relfrozenxid。

  PID  │     DURATION    │                                         QUERY
───────┼─────────────────┼───────────────────────────────────────────────────────────────────────────────────────
 19578 | 02:29:11.200129 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1450645 LIMIT 1
 19465 | 02:26:05.542653 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1889881 LIMIT 1
 19632 | 02:24:46.962818 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1581884 LIMIT 1

此命令显示从 pg_stat_statements 获取的语句，按聚合执行时间排序。这包括语句本身、该语句的总执行时间、该语句占所有语句总执行时间的比例、该语句被调用的次数以及该语句在同步 I/O（从文件系统读取/写入）上花费的时间。

通常，高效的查询将具有适当的调用与总执行时间比率，并尽可能少地花费在 I/O 上。总执行时间高但调用计数低的查询应进行调查以提高其性能。同步 I/O 上花费的执行时间比例高的查询也应进行调查。

                 QUERY                   │ EXECUTION TIME   │ PROPORTION OF EXEC TIME │ NUMBER CALLS │ SYNC IO TIME
─────────────────────────────────────────┼──────────────────┼─────────────────────────┼──────────────┼───────────────
 SELECT * FROM archivable_usage_events.. │ 154:39:26.431466 │ 72.2%                   │ 34,211,877   │ 00:00:00
 COPY public.archivable_usage_events (.. │ 50:38:33.198418  │ 23.6%                   │ 13           │ 13:34:21.00108
 COPY public.usage_events (id, reporte.. │ 02:32:16.335233  │ 1.2%                    │ 13           │ 00:34:19.784318
 INSERT INTO usage_events (id, retaine.. │ 01:42:59.436532  │ 0.8%                    │ 12,328,187   │ 00:00:00
 SELECT * FROM usage_events WHERE (alp.. │ 01:18:10.754354  │ 0.6%                    │ 102,114,301  │ 00:00:00

此命令显示有关数据库上设置的逻辑复制槽的信息。它显示槽是否处于活动状态，WAL 发送进程的状态（“startup”、“catchup”、“streaming”、“backup”、“stopping”），复制客户端地址以及以 GB 为单位的复制延迟。

此命令可用于检查复制延迟量是否尽可能低，复制延迟可能由于网络延迟问题、慢磁盘 I/O、长时间运行的事务或订阅者无法足够快地消费 WAL 而发生。

                       NAME                    │ ACTIVE │ STATE   │ REPLICATION CLIENT ADDRESS │ REPLICATION LAG GB
  ─────────────────────────────────────────────┼────────┼─────────┼────────────────────────────┼─────────────────────
    supabase_realtime_replication_slot         │ t      │ N/A     │ N/A                        │                  0
    datastream                                 │ t      │ catchup │ 24.201.24.106              │                 45

此命令分析表 I/O 模式，以根据块级操作显示读/写活动比率。它结合了 PostgreSQL 的 pg_stat_user_tables（用于元组操作）和 pg_statio_user_tables（用于块 I/O）中的数据，以对每个表的工作负载配置文件进行分类。

该命令将表分类为：

• 读密集型 - 读取操作是写入操作的 5 倍以上（例如，1:10、1:50）
• 写密集型 - 写入操作是读取操作的 20% 以上（例如，1:2、1:4、2:1、10:1）
• 平衡型 - 混合工作负载，写入量在读取量的 20% 到 500% 之间
• 只读 - 仅检测到读取操作
• 只写 - 仅检测到写入操作

SCHEMA │ TABLE        │ BLOCKS READ │ WRITE TUPLES │ BLOCKS WRITE │ ACTIVITY RATIO
───────┼──────────────┼─────────────┼──────────────┼──────────────┼────────────────────
public │ user_events  │     450,234 │     9,004,680│       23,450 │ 20:1 (Write-Heavy)
public │ users        │      89,203 │        12,451│        1,203 │ 7.2:1 (Read-Heavy)
public │ sessions     │      15,402 │        14,823│        2,341 │ ≈1:1 (Balanced)
public │ cache_data   │     123,456 │             0│            0 │ Read-Only
auth   │ audit_logs   │           0 │        98,234│       12,341 │ Write-Only

注意：此命令仅显示具有读写活动的表。不显示没有 I/O 操作的表。分类比率阈值（默认值：5:1）决定了表何时被认为是单向“密集型”与平衡型。

这显示了每个表的 vacuum 活动统计信息。由于 Postgres 的 MVCC，当数据更新或删除时，会创建新行，旧行将变为不可见并标记为“死元组”。通常，autovacuum 进程会异步清理死元组。

该命令列出了上次 vacuum 和上次自动 vacuum 发生的时间，表的行数以及死行数，以及是否预期自动 vacuum 运行。如果死行数远高于行数，或者预期自动 vacuum 但已有一段时间未执行，这可能表明自动 vacuum 无法跟上，并且需要调整您的 vacuum 设置，或者您需要更多的计算或磁盘 IOPS 以允许自动 vacuum 完成。

        SCHEMA        │              TABLE               │ LAST VACUUM │ LAST AUTO VACUUM │      ROW COUNT       │ DEAD ROW COUNT │ EXPECT AUTOVACUUM?
──────────────────────┼──────────────────────────────────┼─────────────┼──────────────────┼──────────────────────┼────────────────┼─────────────────────
 auth                 │ users                            │             │ 2023-06-26 12:34 │               18,030 │              0 │ no
 public               │ profiles                         │             │ 2023-06-26 23:45 │               13,420 │             28 │ no
 public               │ logs                             │             │ 2023-06-26 01:23 │            1,313,033 │      3,318,228 │ yes
 storage              │ objects                          │             │                  │             No stats │              0 │ no
 storage              │ buckets                          │             │                  │             No stats │              0 │ no
 supabase_migrations  │ schema_migrations                │             │                  │             No stats │              0 │ no

为已登录用户创建一个组织。

列出已登录用户所属的所有组织。

提供用于创建和管理您的 Supabase 项目的工具。

此命令组允许您列出组织中的所有项目、创建新项目、删除现有项目和检索 API 密钥。这些操作帮助您以编程方式管理 Supabase 基础设施，而无需使用仪表板。

通过 CLI 进行项目管理对于自动化脚本以及需要以可重复方式提供环境时特别有用。

列出已登录用户可以访问的所有 Supabase 项目。

使用本地 supabase/config.toml 文件更新链接 Supabase 项目的配置。

此命令允许您通过在本地定义设置然后将其推送到远程项目来将项目配置作为代码进行管理。

为链接项目创建一个预览分支。

列出链接项目的所有预览分支。

检索指定预览分支的详细信息。

按名称或 ID 更新预览分支。

按名称或 ID 删除预览分支。

管理 Supabase 边缘函数。

Supabase 边缘函数是运行在靠近用户位置的无服务器函数。

边缘函数允许您执行自定义服务器端代码，而无需部署或扩展传统服务器。它们非常适合处理 Webhook、自定义 API 端点、数据验证和提供个性化内容。

边缘函数用 TypeScript 编写，并在 Deno 兼容的边缘运行时上运行，这是一种安全的运行时，无需包管理，冷启动速度快，并内置安全性。

在 supabase/functions 目录中创建一个带有样板代码的新边缘函数。

此命令生成一个带有必要的 Deno 导入和基本函数结构的入门 TypeScript 文件。该函数将作为一个新目录创建，其名称由您指定，其中包含一个带有函数代码的 index.ts 文件。

创建函数后，您可以在本地编辑它，然后使用 supabase functions serve 在使用 supabase functions deploy 部署之前对其进行测试。

列出链接 Supabase 项目中的所有函数。

从链接 Supabase 项目下载函数的源代码。如果未提供函数名称，则下载所有函数。

在本地提供所有函数服务。

supabase functions serve 命令包含其他标志，以帮助开发人员通过 v8 检查器协议调试边缘函数，例如通过 Chrome DevTools、VS Code 和 IntelliJ IDEA 进行调试。有关设置说明，请参阅文档指南。

1. --inspect

   • --inspect-mode brk 的别名。

2. --inspect-mode [ run | brk | wait ]

   • 激活检查器功能。
   • run 模式仅允许连接，不带额外行为。它不适用于短脚本，但对于长时间运行的脚本，您可能偶尔需要设置断点。
   • brk 模式与 run 模式相同，但额外在第一行设置一个断点，以便在任何代码运行之前暂停脚本执行。
   • wait 模式类似于 brk 模式，但它不是在第一行设置断点，而是暂停脚本执行直到连接了检查器会话。

3. --inspect-main

   • 只能在启用上述两个标志之一时使用。
   • 默认情况下，不允许为主工作程序创建检查器会话，但此标志允许。
   • 其他行为遵循上述 inspect-mode 标志。

此外，以下属性可以通过 supabase/config.toml 中的 edge_runtime 部分进行自定义。

1. inspector_port
   • 用于监听检查器会话的端口，默认为 8083。
2. policy
   • 一个值，指示 edge-runtime 应如何将传入的 HTTP 请求转发给工作程序。
   • per_worker 允许将多个 HTTP 请求转发给已创建的工作程序。
   • oneshot 将强制工作程序处理单个 HTTP 请求然后退出。（调试目的，如果您希望立即反映所做的更改，这特别有用。）

将函数部署到链接的 Supabase 项目。

从链接的 Supabase 项目中删除函数。这不会在本地删除函数。

提供用于管理 Supabase 项目的环境变量和秘密的工具。

此命令组允许您设置、取消设置和列出安全存储并作为环境变量提供给边缘函数的秘密。

通过 CLI 进行秘密管理对于以下方面非常有用：

• 设置特定于环境的配置
• 安全管理敏感凭据

秘密可以单独设置，也可以从 .env 文件加载，以方便起见。

为链接的 Supabase 项目设置一个或多个秘密。

列出链接项目中的所有秘密。

从链接的 Supabase 项目中取消设置一个或多个秘密。

添加和配置到您的 Supabase 项目的 SSO 身份提供者的新连接。

列出您的 Supabase 项目的所有 SSO 身份提供者连接。

提供有关已建立的身份提供者连接的信息。您可以使用 --metadata 获取存储在项目配置中的原始 SAML 2.0 元数据 XML 文档。

返回项目注册 SAML 2.0 兼容身份提供者所需的所有重要 SSO 信息。

更新已添加的 SSO 身份提供者的配置设置。

删除与已添加的 SSO 身份提供者的连接。删除提供者将阻止现有用户登录。请谨慎使用此命令。

管理 Supabase 项目的自定义域名。

自定义域名和个性化子域名不能同时使用。

激活项目的自定义主机名配置。

这将重新配置您的 Supabase 项目以响应自定义主机名上的请求。

自定义主机名激活后，您的项目第三方身份验证提供程序将不再在 Supabase 提供的子域上运行。请参阅我们文档中的准备激活您的域部分，了解您需要遵循的步骤。

为您的 Supabase 项目创建一个自定义主机名。

期望您的自定义主机名具有指向您的 Supabase 项目子域的 CNAME 记录。

检索您的项目在 Supabase 平台中存储的自定义主机名配置。

管理 Supabase 项目的个性化子域名。

个性化子域名和自定义域名的使用是互斥的。

为您的 Supabase 项目激活个性化子域名。

这将重新配置您的 Supabase 项目以响应您的个性化子域名上的请求。个性化子域名激活后，您的项目的身份验证服务将不再在 {project-ref}.{supabase-domain} 主机名上运行。

删除项目的个性化子域名，并恢复使用项目参考进行路由。

网络禁令是指 IP 地址如果其流量模式看起来具有滥用性（例如多次身份验证失败）则会被暂时阻止。

子命令可帮助您查看当前的禁令，并根据需要解除 IP 阻止。

覆盖默认的 Postgres 配置可能导致不稳定的数据库行为。自定义配置还会覆盖根据使用的计算附加组件生成的优化。

删除特定的配置覆盖，将它们恢复为默认值。

列出链接项目的所有 SQL 片段。

下载指定 SQL 片段的内容。

为指定的 shell 生成 supabase 的自动补全脚本。有关如何使用生成的脚本的详细信息，请参阅每个子命令的帮助。

为 zsh shell 生成自动补全脚本。

如果您的环境中尚未启用 shell 补全，则需要启用它。您可以执行以下操作一次

echo "autoload -U compinit; compinit" >> ~/.zshrc

在当前 shell 会话中加载补全

source <(supabase completion zsh)

要为每个新会话加载补全，请执行一次

Linux

supabase completion zsh > "${fpath[1]}/_supabase"

macOS

supabase completion zsh > $(brew --prefix)/share/zsh/site-functions/_supabase

您需要启动新的 shell 才能使此设置生效。

为 powershell 生成自动补全脚本。

在当前 shell 会话中加载补全

supabase completion powershell | Out-String | Invoke-Expression

要为每个新会话加载补全，请将上述命令的输出添加到您的 powershell 配置文件中。

为 fish shell 生成自动补全脚本。

在当前 shell 会话中加载补全

supabase completion fish | source

要为每个新会话加载补全，请执行一次

supabase completion fish > ~/.config/fish/completions/supabase.fish

您需要启动新的 shell 才能使此设置生效。

为 bash shell 生成自动补全脚本。

此脚本依赖于“bash-completion”包。如果尚未安装，您可以通过操作系统的包管理器安装它。

在当前 shell 会话中加载补全

source <(supabase completion bash)

要为每个新会话加载补全，请执行一次

Linux

supabase completion bash > /etc/bash_completion.d/supabase

macOS

supabase completion bash > $(brew --prefix)/etc/bash_completion.d/supabase

您需要启动新的 shell 才能使此设置生效。