supabase私有化部署本质是docker compose编排的容器集群，需确保docker环境就绪、资源充足、网络通畅；关键步骤包括下载官方docker-compose.yml和.env.example、安全配置postgres_password/jwt_secret/anon_key/service_role_key、启动后验证studio（54323）与api（54321）访问，并注意site_url、supabase_public_url绑定及端口暴露策略。
Supabase 私有化部署在 Linux 上本质就是一套 Docker Compose 编排的 PostgreSQL 服务栈，不是“安装软件”，而是“拉起容器集群”。只要 Docker 环境就绪、资源够用、网络通，docker compose up -d 就能跑起来——但直接这么干，90% 的人会在认证失败、API 无法访问、JWT 报错或存储挂载异常上卡住。
怎么用 Docker 快速拉起最小可用 Supabase 实例
别克隆整个仓库，也别手动复制几十个文件。官方 docker 目录已独立发布为可直接使用的配置包：
- 确保已安装
docker和docker compose（v2.0+），运行docker compose version验证 - 执行：
curl -fsSL https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml -o docker-compose.yml curl -fsSL https://raw.githubusercontent.com/supabase/supabase/master/docker/.env.example -o .env
- 编辑
.env：至少改掉POSTGRES_PASSWORD、JWT_SECRET（用openssl rand -base64 32生成）、ANON_KEY和SERVICE_ROLE_KEY（各生成一串 32+ 字符随机字符串） - 启动：
docker compose up -d；1 分钟后访问http://localhost:54323（Studio）和http://localhost:54321（API）
为什么 localhost 能进 Studio 却调不通 API 或报 401
这是最常被忽略的配置点：Supabase 客户端 SDK 默认信任 ANON_KEY，但服务端会校验请求头中的 apikey 是否匹配且未过期，并检查 JWT_SECRET 是否与签发 token 的密钥一致。本地开发时常见错误包括：
-
SITE_URL设为http://localhost:3000，但前端实际跑在http://127.0.0.1:3000—— 浏览器认为这是跨域，认证回调失败 -
SUPABASE_PUBLIC_URL没配或配成http://localhost:54321，导致 SDK 构造的请求地址错误（例如发到localhost:54321/auth/v1/token，而实际容器内网是http://supabase-kong:8000） -
JWT_SECRET在.env里改了，但容器没重启（docker compose down && docker compose up -d才生效） - 用了中文或特殊符号当密码，没加引号导致
.env解析失败，PostgreSQL 启动报错，整个链路中断
如何让外部网络（比如公司内网其他机器）访问你的 Supabase
默认 docker-compose.yml 只暴露了 54321-54324 端口给 localhost，外部无法直连。必须显式放开绑定：
- 编辑
docker-compose.yml，找到kong服务下的ports块，把"54321:8000"改成"0.0.0.0:54321:8000"（或删掉127.0.0.1:前缀） - 确认宿主机防火墙放行该端口：
sudo ufw allow 54321（Ubuntu）或sudo firewall-cmd --add-port=54321/tcp --permanent（CentOS） - 改完务必
docker compose down && docker compose up -d，仅restart不会重载端口映射 - 如果走域名（如
supa.your-company.local），必须同步更新.env中的SUPABASE_PUBLIC_URL和SITE_URL，否则登录跳转会 404
生产环境不能只靠 docker compose up -d
开发模式下所有服务跑在一个 docker-compose.yml 里没问题，但真实生产中必须拆开：数据库要独立持久化卷、Kong 网关需前置 Nginx 做 SSL 终结、对象存储要对接 MinIO 或 Ceph。最容易被跳过的三点是：
-
pg_data卷没做宿主机路径绑定，容器删了，数据库就丢了——必须在volumes下指定绝对路径，如/opt/supabase/pg_data:/var/lib/postgresql/data - 没启用 WAL 归档和
pg_dump定时备份，出事只能回滚镜像，数据不可恢复 - 把
SERVICE_ROLE_KEY泄露到前端代码或日志里——它等同于数据库 root 密码，任何拿到它的人可绕过所有 RLS 策略直接读写全表
真正难的从来不是“怎么跑起来”，而是“怎么不让它随便崩、不让数据随便丢、不让密钥随便漏”。每个 .env 变量、每条 docker compose 端口映射、每次 down 之前的手动备份，都是线上稳定性的具体落点。
