Linux安装Supabase本质是启动Docker容器集群，非安装单个软件；supabase CLI仅是本地开发工具，真正服务需docker compose up -d运行PostgreSQL、Auth等全套组件，无Docker则无法运行。
Linux 上安装 Supabase 不是装一个“软件”，而是拉起一整套 Docker 容器服务；supabase start 本质是 docker compose up -d，没 Docker 就跑不起来，CLI 工具本身不提供数据库或 API 服务。
supabase CLI 安装：只装工具，别当服务用
CLI 是命令行入口，用于 init、login、migrate、start 等操作，但它不是 Supabase 服务本身：
- 别用
sudo npm install -g supabase：容易因 Node 权限导致supabase start报EPERM或找不到二进制文件 - 推荐本地安装：
npm i supabase --save-dev，然后用npx supabase调用 - Homebrew on Linux（linuxbrew）可行但绕路：要先装 gcc，且
brew install supabase/tap/supabase下载的是预编译二进制，和 npm 方式无实质区别 - 验证是否装对：
npx supabase --version能输出版本号，再立刻试npx supabase init—— 如果卡在Logging in...且浏览器打不开，说明系统没注册默认浏览器或DISPLAY环境变量缺失，改用npx supabase login --no-browser手动粘贴授权码
supabase start 失败：90% 是端口、内存或密钥不一致
supabase start 会自动生成 docker-compose.yml 并执行 docker compose up -d，失败原因高度集中：
- 端口冲突：默认占
5432（PostgreSQL）、8000（Studio）、54321（API）、6000（Realtime）；查占用用lsof -i :5432或ss -tulpn | grep ':5432'，杀进程或改.env中的POSTGRES_PORT - 内存不足：全栈最低需 2GB 可用内存；
docker stats看supabase_db是否频繁 OOM，可在docker-compose.yml的dbservice 下加mem_limit: 1.5g - 密钥不一致：首次启动会初始化 DB schema 并写入密钥到
.env；若手动改过POSTGRES_PASSWORD但没重启容器，日志里会出现password authentication failed for user "supabase_admin"，必须docker compose down && docker compose up -d - 启动卡住超 10 分钟：立刻查日志：
docker logs supabase_db和docker logs supabase_kong
真正运行 Supabase：直接用 docker compose 启动最稳
跳过 CLI 的 start，用官方维护的最小配置直启，省去中间层干扰：
- 确保已装
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 - 启动：
docker compose up -d；1 分钟后访问http://localhost:8000（Studio）和http://localhost:54321（API）
外部访问不到？关键在 SUPABASE_PUBLIC_URL 和 SITE_URL
本地能进 Studio，但前端调 API 报 401 或 CORS，几乎全是这两个环境变量配错：
-
SUPABASE_PUBLIC_URL必须设成**可被前端访问的地址**，比如https://supabase.yourdomain.com或http://192.168.1.100:54321；设成http://localhost:54321会导致 SDK 构造的请求发向本机而非容器内网 -
SITE_URL要和前端实际运行地址严格一致（协议 + 域名 + 端口），比如前端跑在http://127.0.0.1:3000，这里就不能写http://localhost:3000，否则认证回调失败 - 改完必须重启：
docker compose down && docker compose up -d，环境变量不会热加载 - 生产务必配 HTTPS，否则 Auth 流程在现代浏览器中会被拦截
最容易被忽略的点是：.env 里改了密钥或 URL，却忘了 down 再 up；容器一旦启动，就按启动时读到的环境变量运行，改文件不重启等于白改。
