Supabase Docker 自架更實用了

Supabase 的 Docker 指南把整套後端搬到自家伺服器，還把安裝、密碼、埠號和更新流程講清楚。

這份文件不是在講概念。它直接告訴你，Linux 上 15 分鐘內可以起來，最低要 4 GB RAM、2 核心 CPU、40 GB SSD。說真的，這種寫法比一堆空話實在多了。

對台灣開發團隊來說，這很有用。你想要 Supabase Docker 指南 的價值，不是因為它很潮，而是因為它把自架最煩的地方先處理掉。

它交出的不是教學，是可直接跑的部署方案

Supabase 這次給的東西很務實。它把 Postgres、Auth、Storage、Realtime、API gateway 一起包進 Docker Compose。你不用自己拼 service，也不用先研究一堆零碎設定。

這種做法很像把自架的坑先填掉。真正麻煩的通常不是啟動容器，而是 secrets、port、proxy、健康檢查。文件裡還放了 run.sh 這種腳本，目的就是少讓人手動打字出錯。

它還把路線分得很清楚。你要快，就走 Linux quick start。你要控管每個檔案，就手動 clone repo。兩條路都能跑，但使用情境完全不同。

• Quick start：只支援 Linux，會自動裝依賴
• 手動安裝：有 Git 和 Docker 就能做
• API gateway 預設 port：8000
• Supavisor 連線：session mode 5432，transaction mode 6543

這份指南最有價值的地方，是把坑先講明白

自架最常死在第一步。不是 Docker 不會跑，是你忘了改密碼、忘了設 URL、或把某個環境變數留成範例值。Supabase 把這些風險直接寫進流程裡，還在 quick start 裡幫你生好 secrets。

它不是只丟一份 compose 檔給你。它會先問網站網址、API 網址、登入回呼網址，接著產生 JWT key 和 dashboard 密碼。這些步驟看起來很瑣碎，但實際上就是避免你半夜救火。

我覺得這裡最聰明的地方，是它承認不同平台的差異。Linux 是最快路線，macOS 和 Windows 也能手動跑。這比那種「理論上都支援」的文件好多了。

“Docker is the easiest way to get started with self-hosted Supabase.” — Supabase Docs

這句話很直白。它不是在吹 Docker，很像在說：別浪費時間自己手刻。對很多團隊來說，這句話其實很中肯。

文件也提醒你，預設密碼和 key 只是範例。這點很重要。很多事故不是架構太差，而是大家懶得換掉預設值。

埠號和 URL 配法，決定你之後會不會痛苦

Supabase 的公開入口通常走 8000。這代表你在本機測試時很直覺，但一旦上 VPS 或前面加 reverse proxy，就要把對外網址和內部服務分開看。

文件把幾個環境變數拆得很細。SUPABASE_PUBLIC_URL 管 dashboard 和 API，API_EXTERNAL_URL 給 Auth callback，SITE_URL 決定預設轉址。這些名字看起來很像，但用途完全不同。

資料庫連線也不是單一路徑。它用 Supavisor 做 pooler，session mode 走 5432，transaction mode 走 6543。你如果連線字串寫錯，問題通常不是資料庫壞掉，而是你接錯層。

• SUPABASE_PUBLIC_URL：dashboard、API、storage 的基底網址
• API_EXTERNAL_URL：Auth callback 用
• SITE_URL：Auth 預設轉址目標
• DASHBOARD_PASSWORD：保護 Studio
• POSTGRES_SECRET：不該外露
• SUPABASE_SECRET_KEY：必須留在伺服器端

如果你前面放了 reverse proxy，事情又會再多一層。外部看到的是 HTTPS 和 443，內部還是 Docker network 那套。這種切分沒什麼浪漫，但很實際。

Windows 使用者也要小心。文件提到，如果 Kong 出現 entrypoint error，常見原因是 CRLF 換行。這種問題很煩，但至少文件先幫你點出來了。

更新策略比拉最新 image 更重要

這段我覺得最值得管理者看。Supabase 說，各版本是一起測過的。意思很簡單：不要看到 Docker Hub 有新 image 就亂 pull。

這跟很多人的直覺相反。大家常以為新就是好，但後端 stack 不是單一容器。Postgres、Auth、Realtime、Storage、gateway 彼此都要對得上。

所以它建議你從 repo 套最新變更，再重啟服務。這種模式比較保守，但也比較穩。對正式環境來說，穩通常比快重要。

• sh run.sh start 等同 docker compose up -d --wait
• docker compose ps 可看服務是否健康
• sh run.sh logs storage 可單看某個服務
• sh run.sh recreate functions 才會更新 Edge Functions

這裡也能看出 Supabase 的操作哲學。它不是要你天天追 image，而是要你按版本節奏升級。這對有維運流程的團隊很友善。

對小團隊來說，這也代表一件事：你得安排維護窗。別把自架想成裝完就沒事。它只是把責任從平台搬回你手上。

跟其他自架後端比，Supabase 的優勢很直接

如果拿 PostgreSQL、Hasura、Appwrite 這類方案來比，Supabase 的強項不是單點功能，而是整包整合。你不用自己把資料庫、驗證、檔案、即時通訊和 API gateway 湊起來。

Hasura 很強，但它偏向 GraphQL 中心。Appwrite 也完整，但它的抽象層和操作習慣和 Supabase 不一樣。Supabase 比較像把開發者常用的資料後端，直接整理成一個可部署的工作台。

和自己從零組 Docker stack 比，Supabase 省掉的是時間，不是複雜度。你還是要懂 port、secret、proxy、備份和升級，只是不用從第一顆螺絲開始鎖。

• Supabase：整合度高，適合 SQL 導向團隊
• Hasura：GraphQL 能力強，但整體後端要自己補
• Appwrite：功能完整，偏另一套開發習慣
• 純自組 stack：彈性最高，但維運成本也最高

如果你的團隊已經很熟 Postgres，Supabase 會比較順手。你不需要先轉換資料模型，也不用為了後端服務再學一套奇怪 DSL。

如果你們很在意資料主權，這份 Docker 指南就更有吸引力。至少你知道資料在哪，服務怎麼跑，升級怎麼做。

這份文件透露的，是 Supabase 對自架市場的判斷

我認為這份指南最大的訊號，是 Supabase 沒把自架寫成英雄任務。它把流程縮短、把參數寫死一部分、把常見錯誤提前講出來。這代表它知道很多團隊其實想要的是可落地，不是可炫技。

它也反映出一個現實。現在很多團隊都想保留雲端彈性，但又不想把核心資料全交出去。自架方案如果太硬，大家就會放棄。Supabase 這次做的是把門檻壓低。

對台灣團隊來說，這很像在說：你可以先用一台便宜 VPS 試跑，再決定要不要上正式環境。先驗證流程，再談規模，這才是比較正常的做法。

先跑一輪，再決定要不要放進正式環境

如果你現在就在評估自架，我會建議先用一台 Linux VM 跑 quick start。先看健康檢查、登入流程、資料庫連線和 reverse proxy 有沒有問題。這四件事過了，才值得往下一步走。

別一開始就把它丟進正式環境。先把 4 GB RAM、2 核心、40 GB SSD 這些條件跑過一次，再決定要不要升到 8 GB 以上。這樣比較不會因為一個小設定，讓整套服務卡住。

講白了，這份 Docker 指南的價值很明確。它不是要你膜拜 Supabase，而是要你少踩坑。如果你接下來要做的是自架後端，我會先問一句：你準備好照著 repo 的節奏更新了嗎？