Side Project 免費 Hosting 完整指南：2026 年還剩下什麼是真的免費

你的 Side Project 做完了，接下來要部署到哪裡才不用花錢？

這篇文章會誠實地告訴你每個平台現在的免費方案長什麼樣子，包含那些已經悄悄消失的。

本文所有數字都是在 2026 年 8 月 6 日重新查過各家官方 pricing 與 docs 頁面後寫的。 這個日期比以前更重要：自從 2025 年版的這篇文章寫完之後，Fly.io 對新用戶完全取消了免費方案，Netlify 把流量和 build 分鐘數整個換成點數制，Railway 的免費額度縮水到原本的五分之一。

免費方案本質上是行銷預算，而行銷預算是會被砍的。在你花一個晚上部署之前，請自己去 pricing 頁面看一眼。

---

快速比較

最後一欄是這次新加的，也是多數教學文章不會講的。你最常看到有人推薦的兩個免費 host，條款上是禁止你賺錢的。 後面會單獨開一節講。

關於 Oracle 那一列： 它是這張表裡唯一一個真的能用 $0 拿到「永遠開著的 VM + 真正的資料庫」的選項，所以即使它是 IaaS 而不是 PaaS，一篇談免費 hosting 的文章也不該漏掉它。但代價大到需要單獨講：Oracle 會回收閒置的 Always Free 運算執行個體。判定標準是任何 7 天區間內，CPU 的 95 百分位、網路、（Arm 機型另加）記憶體使用率全都低於 20%，而這正好就是一個安靜的 Side Project 的側寫。PaaS 那篇有完整的回收規則，決定用它之前請先看那一節。

---

全端 App 的部署選擇

這是變化最大的一類。先講結論：

現在已經沒有任何一家能讓你用 $0 跑一個「永遠開著、附帶資料庫」的小型 web app。

Render 是最接近的，前提是你能接受 app 會睡著。其他家現在都是「付費產品 + 一段免費試用」。

Railway

最適合： Rails、Django、Node.js、Go，而且你願意為了部署體驗付幾塊美金

Railway 依然是全端 app 最好上手的部署平台，push 完程式碼它幾乎什麼都幫你搞定。它現在唯一不是的，就是免費。

Railway 在 2023 年砍掉免費方案，2025 年 8 月 27 日又推出一個小很多的版本。現在有三個常被搞混的東西：

1. Free Trial（試用）：一次性的 $5 額度，30 天到期或用完為止，兩者取先。不需要綁信用卡。每個 project 最多 5 個 service。特別注意：試用帳號建立的 volume，會在額度過期 30 天後被 Railway 刪除，所以你在試用期間存的東西是有時效的。（Railway 自己兩個 docs 頁面對試用的 RAM 上限講法不一致，一個寫 1 GB 一個寫 2 GB，所以不要照著某個數字規劃。）

2. Free 方案：試用結束後你會掉到這裡。$0/月，附帶每月 $1 的用量額度，而且不累積。單一 service 上限：0.5 GB RAM、1 vCPU、1 GB 暫存空間、0.5 GB volume、1 replica、4 GB image。

3. 計費費率：RAM $10/GB/月、vCPU $20/個/月、volume $0.15/GB/月、對外流量 $0.05/GB。你的 $1 就是這樣被吃掉的。

算一下你真正需要的數字：以 $10/GB/月 的 RAM 費率，一個 0.5 GB 的 service 如果整個月都開著，大約要 $5，所以 $1 大概只能買到六天左右的不中斷運行。這是我用 Railway 公布的費率推出來的估算，Railway 官方並沒有公布小時數，所以請當成量級參考而不是承諾。

實務上的解讀是：Free 方案能跑一個不需要一直開著的小服務，僅此而已。

額度用完之後會發生什麼事，這點很關鍵，而且它不是「睡著」。 你的 service 會直接停掉，一直停到下個月額度重置或你升級為止。它不會因為有人來訪就自己醒過來。Railway 真正的 App Sleeping / Serverless 功能（那個會 wake on request 的）只有 Pro 和自動扣款的 Hobby 才有，Free 沒有。

優點：
- 大部分框架零設定
- 一鍵開資料庫
- UI 和開發體驗真的很好
- Nixpacks 會自動判斷你的技術棧

缺點：
- $1/月 不是一個 hosting 方案，是試吃
- 額度用完直接停機，Free 方案沒有 wake on request
- Free 方案（非試用）到底需不需要綁卡，官方文件兩邊都沒寫。pricing 頁面上那句「不需要信用卡」是掛在 Free Trial 上的，別直接套用

部署 Rails app：

# 安裝 Railway CLI
npm install -g @railway/cli

# 登入並部署
railway login
railway init
railway up

小技巧：
- 用 railway run rails db:migrate 跑 migration
- 在 variables 設定 RAILS_ENV=production
- 需要自訂啟動指令就加 Procfile
- 把那 $5 試用當成它本來的用途：30 天決定 Railway 值不值得你付錢

---

Render

最適合： 目前最接近「真・免費全端 hosting」的選擇，前提是你的 app 可以睡

Render 的免費方案還是真的：web service、靜態站、Postgres、Key Value 都還有免費規格。如果你的 Side Project 目前沒有人付錢給你，這是我現在的預設推薦。

免費方案內容：
- 每個 workspace 每個月 750 個 instance 小時。注意是每個 workspace，不是每個 service。所以兩個 service 同時全時運行是塞不下的。睡著的時間不計入這 750 小時。
- 免費 web service 規格：512 MB RAM、0.1 CPU
- 靜態網站
- 免費 Postgres 在建立後 30 天到期（每個 workspace 一個，1 GB 儲存、256 MB RAM、0.1 CPU、100 連線）
- 免費 Key Value（Redis 相容）：每個 workspace 一個，25 MB、50 連線、純記憶體
- 免費 Hobby workspace 另含 5 GB 對外流量、500 分鐘 build pipeline、2 個自訂網域、1 個 seat、25 個 service

Postgres 的 30 天到期是這篇文章最重要的一處更正。 舊版我寫的是 90 天，而它從 2024 年 5 月起就已經是 30 天了。到期後有 14 天寬限期讓你升級成付費 instance，之後資料庫就會被刪除。

如果你當初照我的建議把提醒設在第 85 天，你的資料早就沒了。

另外兩個要在寫 code 之前就知道的限制： 免費 Postgres 上限是 1 GB；免費 Key Value 是純記憶體，每次重啟資料全清，所以它只能當快取。session、你在乎的 job queue，都不要放進去。

睡眠行為： 免費 web service 在 15 分鐘沒有 inbound 流量後會 spin down，下次被叫醒大約要一分鐘，期間訪客會看到一個 loading 頁面。而且 app 寫在本機檔案系統的東西，spin down 之後就沒了。

Workspace 方案在 2026 年 4 月 23 日改版，所有舊 workspace 在 2026 年 8 月 1 日（也就是幾天前）被自動轉換。免費 Hobby workspace 現在只含 5 GB 對外流量（超過每 GB $0.15）、2 個自訂網域（超過每個每月 $0.25）、25 個 service。如果你的 Render 帳號是四月之前開的，你的額度上週剛剛變了。

信用卡： 部署免費服務不需要。只有在你超過流量額度時才需要付款方式。如果你沒綁卡，Render 的做法是把免費服務停到月底而不是跟你收錢。這是你要設計因應的失敗模式。

優點：
- 免費方案是真的免費方案
- 它的「睡」是誠實的睡：下一個請求進來就會醒
- 內建 cron job 和 preview 環境

缺點：
- 15 分鐘就 spin down，冷啟動約一分鐘
- 免費資料庫本質上是 30 天試用
- 5 GB 流量在你的東西紅起來的那天完全不夠

從 GitHub 部署：
1. 連結 GitHub repo
2. 選 "Web Service"
3. 選免費 instance type
4. 設定環境變數
5. 部署

小技巧：
- 不要用 uptime 監控去 ping 你的 app 讓它保持清醒。 睡著的時間不消耗那 750 小時，但一個全天候清醒的 service 一個月大約要吃掉 730 小時。所以「定時 ping 保持清醒」正是害你唯一一個 app 用爆額度被停權的元兇。讓它睡，接受冷啟動。
- 免費 Postgres 建立後，把行事曆提醒設在第 25 天，不是第 85 天。到時候要嘛升級，要嘛 pg_dump 匯出來。
- 免費 Key Value 就當成隨時會不見的快取。
- 吃重的工作丟 background worker。

給台灣讀者的提醒： Render 免費方案的機房都不在台灣，跨海延遲本來就存在，再加上一分鐘的冷啟動，如果你要把連結丟到社群或 demo 給客戶看，第一個點進來的人體驗會很差。實務做法是：在你要分享之前先自己開一次把它叫醒。

---

Fly.io

最適合： 需要全球部署，而且你願意付錢。以前是願不願意的問題，現在沒得選了。

Fly.io 已經沒有免費方案。 Fly 自己的 pricing 文件寫著「Fly.io 不再對新客戶提供方案（no longer offers plans to new customers）」。方案在 2024 年 10 月 7 日被廢止，只有當時已經在方案內的組織還保留。

舊版指南列的那 3 台 shared-cpu-1x VM 和 3 GB volume，現在是給已廢止的 Hobby/Launch/Scale 組織的 legacy 額度。今天註冊的話，一樣都拿不到。以前那個 $5 一次性試用額度是綁在已停售的 $5/月 Hobby 方案上的，新註冊也沒有。

（順帶一提，舊版寫的 160 GB 流量從來沒對過，legacy 額度是北美/歐洲 100 GB、其他地區 30 GB。）

現在的實際費用（開第一台機器就開始算）：
- shared-cpu-1x、256 MB RAM：約 $2.02/月（依 region 而異，這是阿姆斯特丹的數字）
- Volume：已配置容量 $0.15/GB/月，你有沒有用滿都一樣收
- 對外流量：北美與歐洲 $0.02/GB
- 共享 IPv4 免費；專用 IPv4 $2/月

必須綁信用卡。 Fly 明文要求大多數帳號要有有效信用卡才能做「部署多個 app、部署 public image」這類事情。唯一的替代方案是預付至少 $25 美金的 credits。

所以：Fly 上一個最小的 hobby app 大約是 $2/月，再加儲存和流量。這其實很便宜，對真的需要全球分散部署的東西來說也物有所值。但它不是免費，這句話值得講明白，不該塞在括號裡。

台灣讀者要注意兩件事： 一是「必須綁卡或預付 $25」對只是想試玩的人門檻不低，而且都是美金計價，刷台灣的卡還要加國外交易手續費。二是價格會依 region 變動，上面那個 $2.02 是歐洲的數字。如果你打算選離台灣近的機房，請自己到 Fly 的 pricing 頁面確認該 region 的價格，不要直接套用。

優點：
- 很容易部署到多個 region
- 基於 Docker，什麼都跑得起來
- 支援 WebSocket，有代管 Postgres 和 Redis

缺點：
- 完全沒有免費方案
- 需要懂 Docker，設定比 Railway、Render 複雜
- Volume 是按「你申請的大小」收費，不是按用量

用 Fly 部署：

# 安裝 Fly CLI
curl -L https://fly.io/install.sh | sh

# 建立 app
fly launch

# 部署
fly deploy

小技巧：
- 用 fly.toml 設定 region
- 要 scale to zero 請用 Machine 的 auto-stop/auto-start，不是 fly scale count 0。這能把運算費用歸零，但停掉的 Machine 仍然會為它的 root filesystem 收 $0.15/GB/月。閒置很便宜，但不會是免費。
- Volume 開小一點，你付的是申請的容量。

---

前端與靜態網站

Vercel

最適合： 永遠不打算賺錢的 Next.js Side Project

Vercel 依然有最好的前端部署體驗，Hobby 方案的額度也還是很大方。但有兩件事多數教學文章寫錯了。

免費方案（Hobby）：
- 每月 1,000,000 次 edge request、1,000,000 次 function 呼叫
- 4 CPU-hours 的 Active CPU、360 GB-hours 的 Provisioned Memory
- 5,000 次圖片轉換、300,000 次圖片快取讀取、100,000 次寫入
- Web Analytics：每月 50,000 events，保留 1 個月。Speed Insights：10,000 events、1 個專案
- 200 個 project、每天 100 次部署、每個 project 50 個網域
- Build 資源：2 vCPU、8 GB 記憶體、32 GB 磁碟。Runtime log 保留 1 小時
- Function 執行時間上限：300 秒（5 分鐘）

更正一：10 秒的 function 限制已經沒了。 Hobby 的 function 現在可以跑到 300 秒。舊版這篇文章拿那個 10 秒上限當作「長時間工作要丟去 Railway/Render」的理由，現在不成立了。Vercel 的 serverless function 已經可以做真正的事。

更正二：「100GB 流量」已經不是方案內容了。 Vercel 把流量從方案表移到了 Fair Use Guidelines，措辭是「預期多數使用者落在此範圍內」，也就是一個期待值而不是額度：Fast Data Transfer 每月最多 100 GB，以及 Fast Origin Transfer 每月最多 10 GB。

真正會卡到你的是第二個數字。沒有被快取的回應、圖片很多的網站，會在碰到 100 GB 之前老早撞上那 10 GB。不要拿「免費 100GB」來做規劃。

更正三：Hobby 的部署歷史現在只保留 30 天。 2026-04-27 公告、2026-04-29 生效。這影響的是你能往回 rollback 到多久以前的版本，不影響 app 會不會跑，所以嚴重程度比前面兩項小。但在你以為上一季那個 build 還躺在那裡可以回滾之前，最好先知道。

禁止商業用途，而且定義比你想的寬很多。 Vercel 的 fair use 頁面把以下都算成商業使用：接受斗內、任何形式的收款或請求付款、廣告（含 AdSense）、以聯盟行銷連結為主的網站，以及「收取報酬去建置、更新或代管該網站」。

最後那一條對台灣開發者特別有感：接案幫客戶做形象官網、順手丟到自己的 Vercel Hobby 上，這是違規的。 同樣的，你在自己的 Side Project 掛一個「請我喝杯咖啡」按鈕、或串一個綠界、藍新的金流，也踩線。

如果你的 Side Project 有任何一條路通往收入，哪怕只是一個斗內按鈕，Hobby 就是錯的方案。Cloudflare Pages 是那個允許你這樣做的免費替代品。

超過額度時的一般行為是：該功能停止運作，並且要等 30 天才會恢復（Web Analytics 是 7 天）。

信用卡： Vercel 文件從來沒有明講。實際上只有在升級 Pro 的流程才會要求信用卡資訊，所以 Hobby 看起來不需要。但這是推論，不是保證。

部署：

npm install -g vercel
vercel

小技巧：
- 動態內容用 ISR，而且要積極快取。真正緊的是 Fast Origin Transfer
- 沒有持久化儲存，資料庫要外接（Supabase、Neon）
- 只要你的計畫裡有「賺錢」兩個字，改用 Cloudflare Pages

---

Netlify

最適合： 表單。老實說免費方案現在也就剩這個了。

這是整篇文章變動最大的一段，而且它改變的是推薦本身，不只是數字。

在 2025 年 9 月 4 日（含）之後建立的帳號，Netlify 免費方案改為點數制。 你每個月拿到 300 credits。硬上限。不累積、不自動加值，而且免費方案不能加購。

2026 年 4 月 14 日更新後的現行費率：

現在來算那筆你未來會後悔沒算的帳。300 credits 全部拿去換流量是 15 GB。一點流量都不用、全部拿去部署，是 20 次 production deploy。一個普通的小網站，一個月部署 15 次就花掉 225 credits，剩下 75 credits，也就是 3.75 GB 的流量。

大約是舊方案那 100 GB 的二十五分之一。

而且 credits 用完時，Netlify 不會限速也不會跟你收錢，它會把你帳號底下的每一個 project 都暫停，訪客在該月剩下的時間看到的是一頁「Site not available」。

舊的失敗模式是「build 跑不動了」。新的失敗模式是「你的網站直接關燈」。

其他免費限制： 1 個 team owner 且不能加成員、1 個並行 build、500 個 project、1 個 live preview server、Netlify Database 限 3 個資料庫 / 20 個 active branch / 7 天備份保留、analytics 只看得到今天和昨天。不需要信用卡。Deploy preview 和 branch deploy 不算錢，只有成功的 production deploy 才收。這個設計其實很體貼。

舊帳號的陷阱： 2025 年 9 月 4 日之前建立的帳號屬於 Legacy，保留舊的 100 GB 流量 / 300 build 分鐘 / 125K function 呼叫。Legacy 帳號可以轉到點數制，但轉了就回不去。

所以如果你有一個舊的 Netlify 帳號，上面這些完全不適用於你，你甚至會覺得這一段寫錯了。它對今天才註冊的人是正確的。

變好的部分： 表單提交現在免費（舊方案是每月 100 則上限），而且 Netlify Identity 逃過了原本的下架命運：Netlify 在 2026 年 2 月推翻了廢止決定，所以它仍然是可用的 auth 選項。（這個轉折是記在 Netlify 社群論壇而不是主文件裡的，而且我沒有重新確認點數制之下 Identity 的使用者數上限，要用之前請自己查。）

推薦怎麼改： Netlify 免費方案已經不是一個通用靜態 host，它是一個「試用尺寸」的方案，剛好附帶很好用的免費表單。當你明確就是要 Netlify Forms 的時候選它，並且心裡有那個天花板；流量大的東西放 Cloudflare Pages。

拖拉部署：
1. 打開 app.netlify.com
2. 把 dist 或 build 資料夾拖進去
3. 完成

小技巧：
- 把改動累積起來一次部署。每次 production deploy 都是 15 credits，而 deploy preview 是免費的。在 preview 上迭代。
- 設定用 netlify.toml

---

Cloudflare Pages

最適合： 幾乎所有靜態網站，而且越來越像是預設答案

一年前這篇文章對 Cloudflare Pages 寫的每一個數字，今天全部都還是對的。它什麼都沒做，但因為其他家都變差了，它的相對位置變好了。

免費方案：
- 流量與請求數無上限。Cloudflare 的 Workers pricing 文件直接寫明「對靜態資源的請求是免費且無限制的」
- 每月 500 次 build、1 個並行 build
- 每個 project 100 個自訂網域
- 每次部署最多 20,000 個檔案，單一資源上限 25 MiB
- Workers（給 Pages Functions / API route 用）：每天 100,000 次請求，每次呼叫 10 ms CPU 時間
- Workers KV：每天 100,000 次讀、1,000 次寫、1,000 次刪、1,000 次 list，1 GB 儲存
- D1（SQLite）：5 GB 儲存、每天讀 500 萬列、每天寫 100,000 列

值得補充的兩個限制，正好是大家真的會撞到的。20,000 檔案上限是大型文件站或圖很多的靜態專案會先碰到的牆，比流量早得多。而 D1 的每日列數限制比它那個 5 GB 儲存數字緊得多。要拿來規劃的是「每天 10 萬列寫入」，不是儲存空間。

不需要信用卡。不會因為閒置被暫停。允許商業用途。 Cloudflare 對免費方案沒有非商業限制，這就是為什麼只要你的東西有一天可能收錢，它就是正確答案。

優點：
- 真正無上限的流量，零成本，靜態資源沒有 fair use 星號
- 全球 CDN 速度最快
- 同一個免費帳號就有 Workers、KV、D1
- 你被允許賺錢

缺點：
- Workers 的 runtime API 跟 Node.js 不一樣
- 免費 Workers 每次呼叫 10 ms CPU，做任何運算量大的事都很緊
- Cloudflare 現在對比較大的專案推 Workers Static Assets。Pages 沒有被標為停止維護，文件也還是把它當作正常支援的產品，但有一份「從 Pages 遷移到 Workers」的指南存在，方向大概看得出來。

部署：

npm install -g wrangler
wrangler login
wrangler pages deploy ./dist

小技巧：
- API route 用 Workers
- D1 很適合讀多寫少的 app，注意每日寫入上限
- 開啟 Web Analytics（免費）

為什麼台灣讀者特別該考慮它： 一是流量真的無上限。台灣的 Side Project 常常是在 Threads、PTT 或某個社團被轉一次就爆掉，其他平台的月流量額度會在那一天燒完然後關站，Cloudflare 不會。二是它是這份清單裡少數「不綁卡、不禁止商業用途、不會因為閒置停掉」三件事同時成立的平台。

---

GitHub Pages

最適合： 文件、個人網站、開源專案，以及任何你不打算靠它賺錢的東西

從 repo 直接發佈靜態站，最單純的選擇。限制數字本身很穩定，但舊版的兩個描述是錯的。

免費方案：
- 每月 100 GB 流量（軟性上限），不是「無限」
- 每小時 10 次 build（軟性上限）
- 發佈的站台上限 1 GB；原始 repo 建議也在 1 GB 以內
- 自訂網域含 SSL
- 內建 Jekyll

舊版寫的「無限流量（fair use）」是錯的，而且錯在會誤導比較：GitHub Pages 有一個明確的 100 GB/月 數字，跟 Vercel、跟舊制 Netlify 是同一個量級。它不該在比較表裡跟 Cloudflare Pages 並列在「無限」那一格，那個排版暗示了一個不存在的優勢。

商業用途受限。 GitHub 文件寫明 Pages「不得作為免費網頁代管服務，用來經營你的線上生意、電商網站，或任何主要用於促成商業交易或提供商業 SaaS 的網站」。所以你的 SaaS 官網如果上面有結帳流程，這裡不是它該待的地方。

但斗內按鈕和群眾募資連結是明文允許的，這跟 Vercel 的政策剛好相反。如果你在這兩者之間選，兩邊的條款都要讀。

優點：
- 免費、穩定、不綁卡、不會被暫停
- 跟 GitHub 直接整合，Jekyll 完全不用設定

缺點：
- 只能靜態
- GitHub Free 只能用公開 repo：私有 repo 要發 Pages 需要 Pro、Team 或 Enterprise
- 不能做商業 SaaS 或電商

啟用方式：
1. Repo Settings > Pages
2. 選分支（通常是 main 或 gh-pages）
3. 選資料夾（/ 或 /docs）
4. 儲存

小技巧：
- 自訂 build 用 GitHub Actions
- 自訂網域用 CNAME 檔
- 拿來放專案文件非常適合

---

Backend-as-a-Service（BaaS）

Supabase

最適合： 需要 auth、資料庫和 real-time 的 app，最多兩個

Supabase 就是用 PostgreSQL 做的 Firebase，免費方案依然很好。要記住的是專案數上限和暫停機制這兩件事。

免費方案：
- 500 MB 資料庫（共享 CPU、500 MB RAM）
- 1 GB 檔案儲存
- 5 GB 對外流量 + 5 GB 快取流量（舊版寫 2 GB，是低估了）
- Auth 每月 50,000 活躍使用者
- API 請求無上限
- Edge Functions：500,000 次呼叫
- Realtime：200 個並行連線、200 萬則訊息
- Log 保留 1 天
- 最多 2 個 active 專案

2 個專案上限是最容易踩到的遺漏。 如果你手上已經有兩個 Supabase 的 Side Project，第三個就得付費了。在你把 Supabase 當成預設後端之前，先想清楚帳號要怎麼排。

免費專案在大約一週沒有活動後仍然會被暫停。 這件事沒有改變，不要被任何人說服。判斷依據是資料庫活動，Supabase 官方文件的說法是：過去一週每天有幾個使用者請求打到資料庫就足以避免被暫停。暫停前一週左右會收到警告信，暫停時會收到確認信。

被暫停的專案可以在 1 年內還原；超過一年，你就是拿著自己下載的備份手動重建到一個新專案裡。那個一年的懸崖就是「我的專案被暫停了」變成「我的專案沒了」的分界線。

付費專案不會因為閒置被暫停。

信用卡： Supabase 的 pricing 頁面沒有寫免費方案要不要綁卡。我無法確認，註冊時自己看。

優點：
- 完整的 PostgreSQL、row-level security、後台很好用
- 有 self-host 選項，長大了或受不了暫停機制可以搬走

缺點：
- 只能 2 個 active 專案
- 閒置約一週會被暫停
- 檔案塞進資料庫的話 500 MB 很快滿
- RLS 有學習曲線

快速上手：

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://xxx.supabase.co',
  'your-anon-key'
)

// 查詢資料
const { data } = await supabase
  .from('projects')
  .select('*')

小技巧：
- 檔案放 Storage，不要放資料庫
- 開啟 RLS
- 專案要進入冬眠之前，自己下載一份備份，不要只信任那個還原視窗

---

PocketBase

最適合： 零依賴的自架後端

PocketBase 是一個單一執行檔，一次給你資料庫、auth、檔案儲存和管理後台。專案狀態很健康：最新版是 2026 年 7 月 30 日的 v0.39.10，大約每週都有 release，另外還有一條 v0.22.x 舊分支持續在收 backport。

免費方案：
- 完全免費，自己架
- 單一 binary，沒有相依
- SQLite 資料庫
- 內建管理後台

優點：
- 哪裡都能部署（Render、Fly.io、隨便一台 VPS）
- 沒有外部相依
- 內建 real-time 訂閱和檔案儲存
- 維護活躍，每週出版本

缺點：
- 自架就是自己顧，包含備份
- SQLite 限制了你的擴展選項
- 社群比 Supabase 小
- 做了四年還在 1.0 之前：minor 版本之間 API 有可能 breaking change，所以請鎖版本，升級前先讀 release notes

部署方式：這一節我在舊版寫錯了兩個地方。

第一，PocketBase 沒有官方 Docker image。 PocketBase 自己的 production 文件明講了這件事，並且提供一份最小 Dockerfile 當範例。舊版那行 ghcr.io/pocketbase/pocketbase:latest 不存在，照抄的話會 pull 失敗。正確做法是從 release 壓縮檔自己建：

FROM alpine:latest

ARG PB_VERSION=0.39.10

RUN apk add --no-cache unzip ca-certificates

ADD https://github.com/pocketbase/pocketbase/releases/download/v${PB_VERSION}/pocketbase_${PB_VERSION}_linux_amd64.zip /tmp/pb.zip
RUN unzip /tmp/pb.zip -d /pb/

EXPOSE 8080

CMD ["/pb/pocketbase", "serve", "--http=0.0.0.0:8080"]

第二，而且更重要：你必須在 /pb/pb_data 掛一個持久化的 volume。 PocketBase 的 SQLite 資料庫放在那裡，如果它活在 container 檔案系統裡，每次 container 被重建就會消失。

在任何 container 平台上，「container 被重建」是常態，不是意外：每次重新部署、每次重啟都算。沒掛 volume 的話，你上線之後第一次重新部署就會把所有註冊過的使用者清光，而且不會有任何錯誤訊息告訴你。

小技巧：
- /pb/pb_data 掛 volume，然後還是要另外備份
- 鎖住 PB_VERSION，不要追 latest
- 自訂邏輯用 hooks

---

你到底能不能靠它賺錢？

各家免費 host 在這件事上的立場差異很大，而且在你去讀條款之前完全看不出來。如果你的 Side Project 有任何收入企圖，這個限制比任何流量數字都硬。

注意這裡有一個直接的矛盾：一顆「請我喝杯咖啡」的按鈕，在 GitHub Pages 上完全沒問題，在 Vercel 上是違約。

對台灣的接案開發者，還有一條要特別記住：幫客戶做網站然後放在自己的 Vercel Hobby 上，屬於 Vercel 定義的商業使用。 這在台灣是非常常見的做法，而它是違規的。

想要「免費 host + 可以放金流或斗內」，Cloudflare Pages 是最沒有爭議的答案。

---

怎麼選

決策樹

你在做什麼？
│
├── 靜態站 / Landing page
│   └── Cloudflare Pages（流量無上限、可商業用途）
│   └── GitHub Pages（最簡單，但要公開 repo、不能做生意）
│
├── 前端 app（React/Vue/Next.js）
│   ├── 永遠不會賺錢？
│   │   └── Vercel Hobby（Next.js 體驗最好，function 現在可跑 5 分鐘）
│   ├── 有可能賺錢？
│   │   └── Cloudflare Pages
│   └── 就是要免費表單？
│       └── Netlify（但每月 300 credits，歸零就整站關燈）
│
├── 全端 app（Rails/Django/Node）
│   ├── 可以接受睡著？
│   │   └── Render 免費方案（每 workspace 750 小時、15 分鐘 spin down）
│   ├── 要一直開著？
│   │   └── 編列預算：Railway 付費，或 Fly.io 每台機器約 $2/月起
│   └── 記住：任何地方的免費 Postgres 都是暫時的。先決定資料庫。
│
└── 不想寫後端
    └── Supabase（PostgreSQL + Auth；限 2 個專案、閒置會暫停）
    └── PocketBase（自架、單純；備份你自己顧）

依框架

---

免費 Hosting 的實用建議

1. 不要跟「睡眠」對抗

舊的建議是每 10 分鐘 ping 一次，讓 app 永遠不 spin down。在最多人這樣做的兩個平台上，這招現在反而有害。

• 在 Render 上，睡著的時間不消耗那 750 小時。一個全天候清醒的 service 一個月大約吃掉 730 小時，所以定時 ping 正是害你唯一一個 app 用爆 workspace 額度、被停到月底的原因。讓它睡。
• 在 Railway 的 Free 方案上，ping 也沒用。$1 用完之後 service 是停掉不是睡著，再多流量也叫不醒它。

對一個 Side Project 來說，每小時第一個訪客等一分鐘冷啟動，是完全可以接受的取捨。如果真的不能接受，那就是「該付錢買 hosting」的訊號，而不是「該想辦法鑽免費方案漏洞」的訊號。

2. 先規劃資料庫，不是先規劃 app server

免費運算很好找。免費的「持久化儲存」才是稀缺資源，而且每一家的免費方案都在這裡有一道懸崖：

• Render 的 Postgres 建立後 30 天到期，再 14 天就刪除
• Railway 會在試用額度過期 30 天後刪掉試用帳號建立的 volume
• Supabase 閒置一週暫停，保留一年
• PocketBase 在任何 container 平台上沒掛 volume 就會整個 SQLite 不見

先決定資料要住在哪裡、它的有效期是什麼時候，再寫第一個 migration。

3. 為免費額度做最佳化

• 圖片上傳前先壓縮
• 積極快取。Vercel 那 10 GB 的 Fast Origin Transfer 懲罰的正是「沒被快取的回應」
• 非關鍵內容 lazy load
• 在 Netlify 上，用 deploy preview（免費）迭代，不要一直 production deploy（一次 15 credits）

4. 混搭

把服務組合起來依然有效：

• 前端 Cloudflare Pages（流量無上限、可商業）
• API 可以睡的話用 Render 免費方案，不能睡就 Fly.io
• 資料庫 Supabase（注意 2 個專案上限）或你自己控制的付費 Postgres
• 檔案 Cloudflare R2（沒有 egress 費用，不過這一版我沒有重新查證它現在的免費儲存額度，要用之前請自己確認）
• DNS 與 SSL Cloudflare

5. 搞清楚每個平台「壞掉」的方式

它們的失敗方式不一樣，而這個差異決定了一個糟糕的月份會造成多大傷害：

Cloudflare 的「每日重置」比其他家的「月度懸崖」寬容太多，Netlify 的則是最狠的。

---

我推薦的組合

一個典型的 Side Project，2026 年版：

這是真的 $0/月，但帶著 2025 年版沒有的兩個附帶條件：你的 API 會睡著，而且沒人用滿一週你的資料庫會暫停。

如果你要的是一個永遠開著、資料庫由你掌控的 app，誠實的數字已經不是零了。編個大約 $5-10/月 的預算：一個付費 Render instance，或幾台 Fly machine 加一個小 Postgres。然後停止試圖用免費方案做付費方案的工作。

---

什麼時候免費就不夠了

該升級的訊號：

• 冷啟動讓你在第一次點擊就流失使用者
• 免費資料庫快到期了，或已經到期了
• 你想開始收錢，但你的 host 禁止
• Netlify 的 credits 或 Railway 的 $1 每個月都比月底早用完
• 你需要不只一個協作者（Netlify Free 只有 1 個 owner、Render Hobby 只有 1 個 seat、Vercel Hobby 是個人用）

付費方案的價格跟免費方案一樣說變就變，所以請去看 pricing 頁面，不要相信文章裡的數字，包括這一篇。真正穩定的是這個決策的形狀：你花出去的前 $5-10 美金，買到的是「app 不會睡」和「資料庫不會死」，而這通常就是最值得先做的升級。

走到這一步，代表你的 Side Project 是有效的。把一部分收入投回基礎建設吧。

---

分享你部署好的專案

順利把 Side Project 上線了嗎？來 SideShip 跟其他開發者分享，這裡的人都懂從一個想法走到 launch 是什麼感覺。

---

本文所有額度與價格於 2026 年 8 月 6 日對照各服務官方文件重新查證。免費方案隨時可能變動。在你決定用哪個平台之前，先花兩分鐘看一下它的 pricing 頁面。