当前位置：首页 > 文章列表 > 文章 > linux > Linux部署Supabase详细教程

Linux部署Supabase详细教程

2026-04-26 15:46:04 0浏览收藏

本文深入解析了在Linux环境下通过Docker Compose私有化部署Supabase的完整实践路径，不仅手把手教你用几条命令快速拉起最小可用实例，更直击90%用户卡壳的核心痛点——认证失败、API不通、JWT报错、存储丢失和外部访问受限；从.env安全配置（密码、密钥生成与引号避坑）、端口绑定策略、跨域与URL匹配陷阱，到生产级加固（持久化卷绑定、WAL归档、SSL前置、密钥隔离），层层拆解“跑起来”背后的稳定性逻辑，揭示私有化部署真正的挑战不在技术门槛，而在每一个影响数据安全、服务可靠与权限可控的细节决策。

Linux怎么安装和配置Supabase私有化部署 Linux开源Firebase详解

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 之前的手动备份，都是线上稳定性的具体落点。

以上就是《Linux部署Supabase详细教程》的详细内容，更多关于Linux的资料请关注golang学习网公众号！

Linux