# Supabase 企业级自建 > 使用 Pigsty 自托管企业级 supabase，带有监控、高可用、PITR、IaC 以及 575 个 PG 扩展。 --- LLMS index: [llms.txt](/llms.txt) --- Supabase 很好，拥有属于你自己的 supabase 则好上加好。 Pigsty 可以帮助您在自己的服务器上（物理机/虚拟机/云服务器），一键自建企业级 supabase —— 更多扩展，更好性能，更深入的控制，更合算的成本。 > 截至 2026-08，Supabase 的 [官方自托管文档](https://supabase.com/docs/guides/self-hosting) 推荐 Docker，并将其他实现归为社区项目；Pigsty 是独立的社区集成，目前不在该页面的项目列表中。 本教程需要您有 Linux 基础知识，否则建议直接使用 Supabase 云服务或 “Docker Compose” 自建。 -------- ## 简短版本 [准备](/docs/deploy/prepare) [**Linux 系统**](/docs/deploy/prepare)，执行 Pigsty [**标准单机安装**](/docs/setup/install) 流程，选择 `supabase` 配置模板，依次执行： ```bash curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty ./configure -c supabase # 使用 supabase 配置（请在 pigsty.yml 中更改凭据） vi pigsty.yml # 编辑域名、密码、密钥... ./deploy.yml # 标准单机部署 pigsty ./docker.yml -l supabase # 在 supabase 组安装 docker 模块 ./app.yml -l supabase # 在 supabase 组启动无状态容器（可能较慢） ``` 安装完毕后，使用浏览器访问 `8000` 端口造访 Supa Studio，用户名 `supabase`，密码 `pigsty`。 ![Supabase](/img/pigsty/supabase.webp)
demo/supabase.cast
-------- ## 检查清单 - [ ] 至少一台 2C4G 的服务器；完整 Supabase 栈建议 4C8G 或更高 - [ ] 带有静态内网 IPv4 地址 - [ ] 安装支持的 [**Linux 发行版**](/docs/ref/linux) - [ ] [**标准安装**](/docs/setup/install) Pigsty - [ ] 修改配置文件，域名，密码，IP 地址 - [ ] [**安装 Docker 模块**](/docs/docker)，确保代理/镜像站可用 - [ ] 使用 Pigsty 提供的 [`app.yml`](/docs/docker/playbook) 拉起 Supabase ------ ## 目录 - [Supabase是什么？](#supabase是什么) - [为什么要自建它？](#为什么要自建) - [单机自建快速上手](#单节点自建快速上手) - [进阶主题：安全加固](#进阶主题安全加固) - [进阶主题：域名接入](#进阶主题域名接入) - [进阶主题：外部对象存储](#进阶主题外部对象存储) - [进阶主题：使用SMTP](#进阶主题使用smtp) - [进阶主题：真·高可用](#进阶主题真高可用) ------ ## Supabase是什么？ [Supabase](https://supabase.com/) 是一个 BaaS （Backend as Service），开源的 Firebase，是 AI Agent 时代最火爆的数据库 + 后端解决方案。 Supabase 对 PostgreSQL 进行了封装，并提供了身份认证，消息传递，边缘函数，对象存储，并基于 PG 数据库模式自动生成 REST API；按需启用 `pg_graphql` 后，也可以提供 GraphQL API。 Supabase 旨在为开发者提供一条龙式的后端解决方案，减少开发和维护后端基础设施的复杂性。 它能让开发者告别绝大部分后端开发的工作，**只需要懂数据库设计与前端即可快速出活！** 开发者只要用 Vibe Coding 糊个前端与数据库模式设计，就可以快速完成一个完整的应用。 目前，Supabase 是 [PostgreSQL 开源生态](https://ossrank.com/cat/368-postgresql-ecosystem) 中人气最高的开源项目之一；截至 2026-08，其 [GitHub 仓库](https://github.com/supabase/supabase/) 已有超过十万 Star。 Supabase 也提供免费云服务额度；当前 [免费计划](https://supabase.com/pricing) 包含共享 CPU、500 MB 内存、500 MB 数据库额度与 1 GB 文件存储，具体配额以后续官方页面为准。 ------ ## 为什么要自建？ 既然 Supabase 云服务这么香，为什么要自建呢？ 最直观的原因是我们在《[云数据库是智商税吗？](https://vonng.com/cloud/rds/)》中提到过的：当数据、计算或可用性需求超出托管服务套餐的适用范围时，成本可能快速增长。 而且在当下，足够可靠的 [本地企业级 NVMe SSD](https://vonng.com/cloud/bonus/) 在性价比上与 [云端存储](https://vonng.com/cloud/ebs/) 有着三到四个数量级的优势，而自建能更好地利用这一点。 另一个重要的原因是 **功能**， Supabase 云服务的功能受限 —— 很多强力 PG 扩展因为多租户安全挑战与许可证的原因无法以云服务的形式。 故而尽管 [扩展是 PostgreSQL 的核心特色](https://vonng.com/pg/pg-eat-db-world)，Supabase 官方当前只承诺 [预配置 50 多个扩展](https://supabase.com/docs/guides/database/extensions)，具体清单还会随平台版本变化。 而通过 Pigsty 自建的 Supabase 则提供了多达 [**575**](/ext/list/) 个开箱即用的 PG 扩展。 此外，自主可控与规避供应商锁定也是自建的重要原因 —— 尽管 Supabase 虽然旨在提供一个无供应商锁定的 Google Firebase 开源替代，但实际上自建高标准企业级的 Supabase 门槛并不低。 Supabase 内置了一系列由他们自己开发维护的 PG 扩展。Supabase 在 2024 年收购了 Oriole 团队，并把 [**OrioleDB**](/docs/pgsql/kernel/orioledb) 作为可选 Public Alpha 提供；它不是生产环境默认内核，也不能表述为已计划替换原生 PostgreSQL。部分 Supabase 扩展和带补丁内核不由 PGDG 官方仓库提供。 这实际上是某种隐性的供应商锁定，阻止了用户使用除了 supabase/postgres Docker 镜像之外的方式自建，Pigsty 则提供开源，透明，通用的方案解决这个问题。 我们将 Supabase 自研与用到的 10 个缺失扩展打成开箱即用的 RPM/DEB 包，覆盖当前 `supabase` 模板声明支持的 [Linux 发行版](/docs/ref/linux)：EL 8/9、Debian 12、Ubuntu 22.04/24.04/26.04，以及 x86_64/aarch64 架构。 | 扩展 | 说明 | |------------------------------------------|------------------------------------------------------------| | [`pg_graphql`](/ext/e/pg_graphql/) | 提供 PG 内的 GraphQL 支持 (RUST)，Rust 扩展，由 PIGSTY 提供，按需启用 | | [`pg_jsonschema`](/ext/e/pg_jsonschema/) | 提供 JSON Schema 校验能力，Rust 扩展，由 PIGSTY 提供 | | [`wrappers`](/ext/e/wrappers/) | Supabase 提供的外部数据源包装器捆绑包，Rust 扩展，由 PIGSTY 提供 | | [`index_advisor`](/ext/e/index_advisor/) | 查询索引建议器，SQL 扩展，由 PIGSTY 提供 | | [`pg_net`](/ext/e/pg_net/) | 用 SQL 进行异步非阻塞 HTTP/HTTPS 请求的扩展 (supabase)，C 扩展，由 PIGSTY 提供 | | [`vault`](/ext/e/supabase_vault/) | 在 Vault 中存储加密凭证的扩展 (supabase)，C 扩展，由 PIGSTY 提供 | | [`pgjwt`](/ext/e/pgjwt/) | JSON Web Token API 的 PG 实现 (supabase)，SQL 扩展，由 PIGSTY 提供 | | [`pgsodium`](/ext/e/pgsodium/) | 表数据加密存储 TDE，扩展，由 PIGSTY 提供 | | [`supautils`](/ext/e/supautils/) | 用于在云环境中确保数据库集群的安全，C 扩展，由 PIGSTY 提供 | | [`pg_plan_filter`](/ext/e/plan_filter/) | 使用执行计划代价过滤阻止特定查询语句，C 扩展，由 PIGSTY 提供 | {.full-width} 同时，我们在 Supabase 自建部署中默认 [安装](/docs/pgsql/ext/install) 绝大多数扩展，您可以参考可用扩展列表按需 [启用](/docs/pgsql/ext/create)。 新版模板会安装 `pg_graphql` 扩展包，但不再默认创建 `pg_graphql` 扩展对象；如果需要 GraphQL API，可以在目标数据库中执行 `CREATE EXTENSION IF NOT EXISTS pg_graphql;`，模板中的事件触发器会自动重建 `graphql_public.graphql` 入口与访问权限。 同时，Pigsty 还会负责好底层 [高可用](/docs/concept/ha/) [PostgreSQL](/docs/pgsql/) 数据库集群，高可用 [Silo](/docs/minio/) 对象存储集群的自动搭建，甚至是 [Docker](/docs/docker/) 容器底座的部署与 [Nginx](/docs/infra/admin/portal) 反向代 理，[域名配置](/docs/infra/admin/domain) 与 [HTTPS证书签发](/docs/infra/admin/cert)。 您可以使用 Docker Compose 拉起任意数量的无状态 Supabase 容器集群，并将状态存储在外部 Pigsty 自托管数据库服务中。 在这一自建部署架构中，您获得了使用不同内核的自由（当前模板支持 PostgreSQL 15-18，默认 18），加装 [**575**](/ext/list/) 个扩展的自由，扩容与伸缩 Supabase / Postgres / Silo 的自由， 免于数据库运维杂务的自由，以及免于供应商锁定，本地运行到地老天荒的自由。 而相比于使用云服务需要付出的代价，不过是准备服务器和多敲几行命令而已。 ------ ## 单节点自建快速上手 让我们先从单节点 Supabase 部署开始，我们会在后面进一步介绍多节点高可用部署的方法。 [准备](/docs/deploy/prepare) 一台全新 [Linux 服务器](/docs/deploy/prepare)，使用 Pigsty 提供的 [`supabase`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml) 配置模板执行 [标准安装](/docs/setup/install)， 然后额外运行 [`docker.yml`](/docs/docker/playbook#dockeryml) 与 `app.yml` 拉起无状态部分的 Supabase 容器即可（默认端口 `8000`/`8443`）。 ```bash curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty ./configure -c supabase # 使用 supabase 配置（请在 pigsty.yml 中更改凭据） vi pigsty.yml # 编辑域名、密码、密钥... ./deploy.yml # 安装 pigsty ./docker.yml -l supabase # 在 supabase 组安装 docker compose 组件 ./app.yml -l supabase # 在 supabase 组启动无状态容器 ``` 在部署 Supabase 前请根据实际情况修改自动生成的 `pigsty.yml` 配置文件中的参数（域名与密码） 如果只是本地开发测试，可以先跳过，我们将在后面介绍如何通过修改配置文件来进一步定制。 如果配置无误，大约十分钟后，就可以在本地网络通过 `http://:8000` 访问到 Supabase Studio 图形管理界面了。 默认的用户名与密码分别是： `supabase` 与 `pigsty`。 ![Supabase](/img/pigsty/supabase.webp) **注意事项：** - 在中国大陆地区，Pigsty 默认使用 1Panel 与 1ms 提供的 DockerHub 镜像站点下载 Supabase 相关镜像，可能会较慢。 - 你也可以自行配置 [代理](/docs/docker/usage#代理) 与 [镜像站](/docs/docker/usage#镜像站)，`cd /opt/supabase; docker compose pull` 手动拉取镜像。我们亦提供包含完整离线安装方案的 Supabase 自建专家咨询服务。 - 如果你需要使用的对象存储功能，那么需要通过域名与 HTTPS 访问 Supabase，否则会出现报错。 - 对于严肃的生产部署，请 **务必** 修改所有默认密码！ ------ ## 自建关键技术决策 以下是一些自建 Supabase 会涉及到的关键技术决策，供您参考： 使用默认的 **单节点部署** Supabase 无法享受到 PostgreSQL / Silo 的高可用能力。 尽管如此，单节点部署相比官方纯 Docker Compose 方案依然要有显著优势： 例如开箱即用的监控系统，自由安装扩展的能力，各个组件的扩缩容能力，以及提供兜底数据库时间点恢复能力等。 Pigsty 的 Supabase 模板不启动上游 Compose 中的 `db` 与 `supavisor` 容器，也不使用 Supabase 自带连接池。 无状态容器直接通过 Pigsty 管理的 PostgreSQL 服务接入数据库；单节点模板中默认使用 `5436` 服务端口，它始终路由到当前主库。 模板中的 Logflare / Analytics 不再写入业务库的 `postgres._analytics`，而是使用独立的 `_supabase` 数据库与其中的 `_analytics` 模式。 这样可以避免 `oban_jobs`、`oban_peers` 等内部调度表落在项目库的 `public` 模式中，触发 Supabase Advisor 的 RLS 告警；相关位置由 `LOGFLARE_DB` 与 `LOGFLARE_SCHEMA` 控制。 Supabase Studio 的 Query Performance 页面会在 `public, extensions` 搜索路径下访问 `pg_stat_statements`。 Pigsty 仍然将 `pg_stat_statements` 扩展对象保留在 `monitor` 模式中，以兼容 `pg_exporter` 与现有监控面板；模板会在 `extensions` 模式中创建兼容视图与函数，供 Studio 使用。 如果您只有一台服务器，或者选择在云服务器上自建，Pigsty 建议您使用外部的 S3 替代本地的 Silo 作为对象存储，存放 PostgreSQL 的备份，并承载 Supabase Storage 服务。 这样的部署可在单机故障后提供小时级恢复的兜底路径；实际 RPO 取决于最近一次可恢复备份、WAL 归档状态与对象存储可用性，不能仅凭该拓扑承诺固定数值。 在严肃的生产部署中，Pigsty 建议使用至少 3～4 个节点的部署策略，确保 Silo 与 PostgreSQL 都使用满足企业级高可用要求的多节点部署。 在这种情况下，您需要相应准备更多节点与磁盘，并相应调整 `pigsty.yml` 配置清单中的集群配置，以及 supabase 集群配置中的接入信息，使用高可用接入点访问服务。 Supabase 的部分功能需要发送邮件，所以要用到 SMTP 服务。除非单纯用于内网，否则对于严肃的生产部署，建议使用 SMTP 云服务。自建的邮件服务器发送的邮件容易被标记为垃圾邮件导致拒收。 如果您的服务直接向公网暴露，我们强烈建议您使用真正的域名与 HTTPS 证书，并通过 [Nginx 门户](/docs/infra/admin/portal) 访问。 接下来，我们会依次讨论一些进阶主题。如何在单节点部署的基础上，进一步提升 Supabase 的安全性、可用性与性能。 ------ ## 进阶主题：安全加固 **Pigsty 基础组件** 对于严肃的生产部署，我们强烈建议您修改 Pigsty 基础组件的密码。因为这些默认值是公开且众所周知的，不改密码上生产无异于裸奔： - [`grafana_admin_password`](/docs/infra/param/#grafana_admin_password): `pigsty`，Grafana 管理员密码 - [`pg_admin_password`](/docs/pgsql/param/#pg_admin_password): `DBUser.DBA`，PG 超级用户密码 - [`pg_monitor_password`](/docs/pgsql/param/#pg_monitor_password): `DBUser.Monitor`，PG 监控用户密码 - [`pg_replication_password`](/docs/pgsql/param/#pg_replication_password): `DBUser.Replicator`，PG 复制用户密码 - [`patroni_password`](/docs/pgsql/param/#patroni_password): `Patroni.API`，Patroni 高可用组件密码 - [`haproxy_admin_password`](/docs/node/param/#haproxy_admin_password): `pigsty`，负载均衡器管控密码 - [`minio_secret_key`](/docs/minio/param/#minio_secret_key): `S3User.MinIO`，Silo 根用户密钥 - [`etcd_root_password`](/docs/etcd/param/#etcd_root_password): `Etcd.Root`，Etcd 根用户密码 - 此外，强烈建议您修改 Supabase 使用的 [PostgreSQL 业务用户](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L72) 密码，默认为 `DBUser.Supa` 以上密码为 Pigsty 组件模块的密码，强烈建议在安装部署前就设置完毕。 **Supabase 密钥** 除了 Pigsty 组件的密码，你还需要 [修改 Supabase 的密钥](https://supabase.com/docs/guides/self-hosting/docker#securing-your-services)，包括 - [`JWT_SECRET`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L140)：JWT 签名密钥，长度至少 32 个字符 - [`ANON_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L141)：匿名用户的 JWT 凭据 - [`SERVICE_ROLE_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L142)：服务角色的 JWT 凭据 - [`SUPABASE_PUBLISHABLE_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L143) / [`SUPABASE_SECRET_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L144)：新版不透明 API Key，未启用时可以留空 - [`JWT_KEYS`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L145) / [`JWT_JWKS`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L146)：非对称 JWT 密钥与 JWKS，未启用时可以留空 - [`ANON_KEY_ASYMMETRIC`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L147) / [`SERVICE_ROLE_KEY_ASYMMETRIC`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L148)：非对称签名 JWT，未启用时可以留空 - [`PG_META_CRYPTO_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L149)：PostgreSQL Meta 服务的加密密钥，长度至少 32 个字符 - [`SECRET_KEY_BASE`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L150)：Realtime 使用的随机密钥 - [`REALTIME_DB_ENC_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L151)：Realtime 数据库加密密钥 - [`DASHBOARD_USERNAME`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L153)：Supabase Studio Web 界面的默认用户名，默认为 `supabase` - [`DASHBOARD_PASSWORD`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L154)：Supabase Studio Web 界面的默认密码，默认为 `pigsty` - [`LOGFLARE_PUBLIC_ACCESS_TOKEN`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L157)：Logflare 公开访问令牌，至少 32 个随机字符 - [`LOGFLARE_PRIVATE_ACCESS_TOKEN`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L158)：Logflare 私有访问令牌，至少 32 个随机字符 - [`LOGFLARE_DB`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L159) / [`LOGFLARE_SCHEMA`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L160)：Logflare / Analytics 使用的内部数据库与模式，默认是 `_supabase` / `_analytics` 这里请您务必参照 [Supabase教程：保护你的服务](https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys) 里的说明： - 生成一个长度超过 40 个字符的 `JWT_SECRET`，并使用教程中的工具签发 `ANON_KEY` 与 `SERVICE_ROLE_KEY` 两个 JWT。 - 使用教程中提供的工具，根据 `JWT_SECRET` 以及过期时间等属性，生成一个 `ANON_KEY` JWT，这是匿名用户的身份凭据。 - 使用教程中提供的工具，根据 `JWT_SECRET` 以及过期时间等属性，生成一个 `SERVICE_ROLE_KEY`，这是权限更高服务角色的身份凭据。 - 如果您使用新版不透明 API Key 或非对称 JWT，请同步生成并填写 `SUPABASE_PUBLISHABLE_KEY`、`SUPABASE_SECRET_KEY`、`JWT_KEYS`、`JWT_JWKS` 与对应的非对称 `ANON_KEY` / `SERVICE_ROLE_KEY`。 - 指定一个32个字符以上的随机字符串密钥 `PG_META_CRYPTO_KEY`，用于加密 Studio UI 与 meta 服务的交互 - `SECRET_KEY_BASE` 至少 64 个字符；`REALTIME_DB_ENC_KEY` 必须恰好 16 个字符。 - 为 `S3_PROTOCOL_ACCESS_KEY_ID` 与 `S3_PROTOCOL_ACCESS_KEY_SECRET` 生成独立随机凭据，不要复用对象存储管理员密码。 - 如果您使用的 PostgreSQL 业务用户使用了不同于默认值的密码，请相应修改 [`POSTGRES_PASSWORD`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L166) 的值 - 如果您的对象存储使用了不同于默认值的密码，请相应修改 [`S3_ACCESS_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L177) 与 [`S3_SECRET_KEY`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L178) 的值 - 如果您将 Edge Functions 暴露给不可信客户端，请按需将 [`FUNCTIONS_VERIFY_JWT`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L191) 改为 `true`。 - [`API_EXTERNAL_URL`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L170) 现在应填写 Auth 服务的外部 URL，保留 `/auth/v1` 后缀，例如 `https://supa.pigsty.cc/auth/v1`；`SITE_URL` 与 `SUPABASE_PUBLIC_URL` 保持站点根 URL。 - 当前模板的 [`PGRST_DB_SCHEMAS`](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L187) 默认为 `public,graphql_public`；`storage` 模式由 Storage API 使用，不再通过 PostgREST 默认暴露。 Supabase 部分的凭据修改后，您可以重启 Docker Compose 容器以应用新的配置： ```bash ./app.yml -l supabase -t app_config,app_launch # 使用剧本 cd /opt/supabase; make up # 手工执行 ``` ------ ## 进阶主题：域名接入 如果你在本机或局域网内使用 Supabase，那么可以选择 IP:Port 直连 Kong 对外暴露的 HTTP 8000 端口访问 Supabase。 你可以使用一个内网静态解析的域名，但对于严肃的生产部署，我们建议您使用真域名 + HTTPS 来访问 Supabase。 在这种情况下，您的服务器应当有一个公网 IP 地址，你应当拥有一个域名，使用云/DNS/CDN 供应商提供的 DNS 解析服务，将其指向安装节点的公网 IP（可选默认下位替代：本地 `/etc/hosts` 静态解析）。 比较简单的做法是，直接批量替换占位域名（`supa.pigsty`）为你的实际域名，假设为 `supa.pigsty.cc`： ```bash sed -ie 's/supa.pigsty/supa.pigsty.cc/g' ~/pigsty/pigsty.yml ``` 如果你没有事先配置好，那么重载 Nginx 和 Supabase 的配置生效即可： ```bash make cert # 申请 certbot 免费 HTTPS 证书 ./app.yml -l supabase -t app_config,app_launch # 重载 Supabase 配置 ``` 修改后的配置应当类似下面的片段： ```yaml all: vars: certbot_sign: true # 使用 certbot 签发真实证书 infra_portal: home: { domain: i.pigsty.cc } # 替换为你的域名！ supa: domain: supa.pigsty.cc # 替换为你的域名！ endpoint: "10.10.10.10:8000" websocket: true certbot: supa.pigsty.cc # 证书名称，通常与域名一致即可 children: supabase: vars: apps: supabase: # supabase 应用定义 conf: # 覆盖 /opt/supabase/.env SITE_URL: https://supa.pigsty.cc # <------- 修改为您的外部域名 API_EXTERNAL_URL: https://supa.pigsty.cc/auth/v1 # <--- Auth 服务外部 URL，保留 /auth/v1 SUPABASE_PUBLIC_URL: https://supa.pigsty.cc # <------- 别忘了在 infra_portal 中配置！ ``` 完整的域名/HTTPS 配置可以参考 [证书管理](/docs/infra/admin/cert) 教程，您也可以使用 Pigsty 自带的本地静态解析与自签发 HTTPS 证书作为下位替代。 ------ ## 进阶主题：外部对象存储 您可以使用 S3 或 S3 兼容的服务，来作为 PGSQL 备份与 Supabase 使用的对象存储。这里我们使用一个 阿里云 OSS 对象存储作为例子。 > Pigsty 提供了一个 [`terraform/spec/aliyun-s3.tf`](https://github.com/pgsty/pigsty/blob/main/terraform/spec/aliyun-s3.tf) 模板， > 可以用于在阿里云上拉起一台服务器，以及一个 OSS 存储桶。 首先，修改 `all.children.supabase.vars.apps.supabase.conf` 中 S3 相关的配置，将其指向阿里云 OSS 存储桶： ```yaml # if using s3/minio as file storage S3_BUCKET: pigsty-supa # 兼容旧模板，与 GLOBAL_S3_BUCKET 保持一致 GLOBAL_S3_BUCKET: pigsty-supa # Supabase Storage 实际使用的 bucket S3_ENDPOINT: https://oss-cn-beijing.aliyuncs.com S3_ACCESS_KEY: S3_SECRET_KEY: S3_FORCE_PATH_STYLE: false # 阿里云 OSS 使用 host-style URI S3_PROTOCOL: https S3_REGION: oss-cn-beijing # 兼容旧模板，与 REGION 保持一致 REGION: oss-cn-beijing # Supabase Storage 实际使用的 region STORAGE_TENANT_ID: pigsty # Supabase Storage tenant id S3_PROTOCOL_ACCESS_KEY_ID: S3_PROTOCOL_ACCESS_KEY_SECRET: ``` 同样使用以下命令重载 Supabase 配置： ```bash ./app.yml -l supabase -t app_config,app_launch ``` 您同样可以使用 S3 作为 PostgreSQL 的备份仓库，在 `all.vars.pgbackrest_repo` 新增一个 `aliyun` 备份仓库的定义： ```yaml all: vars: pgbackrest_method: aliyun # pgBackRest 备份方法：local、minio 或其他自定义仓库；本例使用阿里云 OSS pgbackrest_repo: # pgbackrest 备份仓库: https://pgbackrest.org/configuration.html#section-repository aliyun: # 定义一个新的备份仓库 aliyun type: s3 # 阿里云 oss 是 s3-兼容的对象存储 s3_endpoint: oss-cn-beijing-internal.aliyuncs.com s3_region: oss-cn-beijing s3_bucket: pigsty-oss s3_key: xxxxxxxxxxxxxx s3_key_secret: xxxxxxxx s3_uri_style: host path: /pgbackrest bundle: y # bundle small files into a single file bundle_limit: 20MiB # Limit for file bundles, 20MiB for object storage bundle_size: 128MiB # Target size for file bundles, 128MiB for object storage cipher_type: aes-256-cbc # enable AES encryption for remote backup repo cipher_pass: pgBackRest.MyPass # 设置一个加密密码，pgBackRest 备份仓库的加密密码 retention_full_type: time # retain full backups by time in this S3 repository retention_full: 14 # keep full backup for the last 14 days ``` 然后在 `all.vars.pgbackrest_method` 中指定 `aliyun`。先核对现有备份，再在明确授权后对目标集群重新渲染 pgBackRest 配置、初始化 stanza，并立即建立新的全量恢复点： ```bash pig pb info ./pgsql.yml -t pg_backup -l pg-meta pg-backup full ``` 旧仓库中的备份不会自动迁移；新仓库首次全量备份成功前存在恢复窗口缺口。完整步骤与注意事项见 [PostgreSQL 备份仓库](/docs/pgsql/backup/repository/#切换仓库)。 ------ ## 进阶主题：使用SMTP 你可以使用 SMTP 来发送邮件，修改 supabase 应用配置，添加 SMTP 信息： ```yaml all: children: supabase: # supa group vars: # supa group vars apps: # supa group app list supabase: # the supabase app conf: # the supabase app conf entries SMTP_HOST: smtpdm.aliyun.com SMTP_PORT: 80 SMTP_USER: no_reply@mail.your.domain.com SMTP_PASS: your_email_user_password SMTP_SENDER_NAME: MySupabase SMTP_ADMIN_EMAIL: adminxxx@mail.your.domain.com ENABLE_ANONYMOUS_USERS: false ``` 不要忘了使用 `./app.yml -l supabase -t app_config,app_launch` 重载配置。 ------ ## 进阶主题：真·高可用 经过这些配置，您拥有了一个带公网域名，HTTPS 证书，SMTP，PITR 备份，监控，IaC，以及 575 个扩展的企业级 Supabase （基础单机版）。 高可用的配置请参考 Pigsty 其他部份的文档，如果您懒得阅读学习，我们提供手把手扶上马的 Supabase 自建专家咨询服务 —— ¥2000 元免去折腾与下载的烦恼。 单节点的 RTO / RPO 依赖外部对象存储服务提供兜底，如果您的这个节点挂了，外部 S3 存储中保留了备份，您可以在新的节点上重新部署 Supabase，然后从备份中恢复。 这种拓扑可以提供小时级恢复的 [兜底路径](/docs/pgsql/backup)，但 RPO 取决于备份与 WAL 归档的实际状态，必须通过恢复演练验证，不能用“MB 级”作为固定承诺。 若目标是 RTO < 30s 且已确认事务在切换时不丢失，需要使用多节点，并显式选择 `fast` RTO 预设与 `crit.yml` 严格同步策略后进行故障演练；默认 `norm` 预设的目标是 RTO < 45s，异步复制不承诺 RPO=0。这涉及到： - [ETCD](/docs/etcd/)： DCS 需要使用三个节点或以上，才能容忍一个节点的故障。 - [PGSQL](/docs/pgsql/)： PGSQL 同步提交不丢数据模式，建议使用至少三个节点。 - [INFRA](/docs/infra/)：监控基础设施故障影响稍小，建议生产环境使用双副本 - Supabase 无状态容器本身也可以是多节点的副本，可以实现高可用。 在这种情况下，您还需要修改 PostgreSQL 与 Silo 的接入点，使用 DNS / L2 VIP / HAProxy 等 [高可用接入点](/docs/pgsql/service#接入服务) 关于这些部分，您只需参考 Pigsty 中各个模块的文档进行配置部署即可。 建议您参考 [`conf/ha/trio.yml`](https://github.com/pgsty/pigsty/blob/main/conf/ha/trio.yml) 与 [`conf/ha/safe.yml`](https://github.com/pgsty/pigsty/blob/main/conf/ha/safe.yml) 中的配置，将集群规模升级到三节点或以上。