免費開發工具全攻略：資料庫、Server、部署一次打包

以前想生一個 side project，光是「主機錢從哪來」就會讓念頭停在腦中：VPS 要月租、資料庫要自己裝、網域要花錢、SSL 要自己搞。門檻不是技術，是啟動成本。

現在這個問題基本上不存在了。資料庫、向量資料庫、快取、Server、部署、Email、設計素材，全部都有夠用的免費層，一路串起來可以做到「使用者掛掉之前完全不用付錢」。這篇整理目前常見的免費開發工具，分成 資料庫、向量資料庫、快取、後端／Server、部署、Email、設計 幾大塊，最後給一個可以直接照抄的免費組合，並提醒這些終究只適合開發階段——真的要上線，要有換成付費方案的準備。

資料庫（Database）

資料庫曾經是最貴、最麻煩的一塊：要嘛自己在 VPS 上裝，要嘛付錢買代管。現在雲端資料庫服務幾乎都有免費層可以長期使用（不是試用期），選型只看你熟悉的資料模型。

選擇建議：不確定要選什麼就先用 Supabase——它把資料庫、登入、檔案儲存包在一起，省下串接三個服務的時間，很適合一個人從零到有的階段。之後真的成長到需要拆分，再各自換掉也不遲。

向量資料庫（Vector Database）

想做語意搜尋、RAG、推薦系統這類跟 AI 相關的功能，遲早會碰到向量資料庫，但不代表要一開始就自己架 Milvus。

選擇建議：已經用 Supabase 當主資料庫，就直接開 pgvector 擴充套件，不用多學一套 SDK；如果是專門做搜尋／推薦系統、資料量會成長很快，再考慮 Pinecone 或 Qdrant 這類專用服務。

快取（Cache）

Session、rate limit、常用查詢結果，這些不想每次都打資料庫的東西，過去要自己維運一台 Redis，現在同樣有 serverless 的免費層。

• Upstash Redis：Serverless Redis，用 REST API 呼叫，特別適合 Edge Function／Serverless 這種不能維持長連線的環境，免費額度對個人專案通常夠用。
• Vercel KV：底層其實就是 Upstash，接在 Vercel 專案裡幾乎零設定。
• Cloudflare KV：邊緣 key-value 儲存，跟 Cloudflare Workers 搭配，免費額度大，適合設定值、快取這類讀多寫少的資料。
• Redis Cloud 免費層：如果就是想要一個「傳統」Redis instance、之後可能要換自架，這個路徑比較好遷移。

判斷方式：在 Serverless／Edge 架構下優先選 Upstash 或 Cloudflare KV；如果本來就打算跑常駐服務，用 Redis Cloud 免費層即可。

後端／Server

「養一台 Server」曾經意味著要處理作業系統更新、防火牆、SSL 憑證續期。現在多數 side project 根本不需要一台一直開著的機器。

• Serverless Functions：Vercel Functions、Netlify Functions、Cloudflare Workers——寫一支函式當 API endpoint，沒人呼叫就不計費，免費額度對個人專案通常綽綽有餘。
• BaaS（Backend as a Service）：Supabase、Firebase 直接把常見後端需求（登入、資料庫、檔案、推播）包成 SDK，前端直接呼叫，很多小工具甚至可以完全不用自己寫後端。
• 傳統 PaaS 免費層：Render、Railway、Fly.io 這類平台可以跑常駐的 Node/Python/Go 服務，免費層通常會有休眠或用量限制，但拿來跑一個小 API 或個人專案完全夠用。

判斷方式很簡單：如果你的邏輯是「收到請求、算一算、回傳結果」，用 Serverless Functions；如果你需要一個長駐的 WebSocket 連線或背景排程，才考慮 PaaS 常駐服務。多數個人專案其實用不到後者。

部署（Deploy）

部署這塊進化最明顯。過去要自己設定 Nginx、處理 HTTPS、寫部署腳本；現在只要把程式碼 push 上 GitHub，後面幾乎全自動。

• 靜態網站／前端框架：Vercel、Netlify、Cloudflare Pages——接上 GitHub repo，每次 push 自動 build、自動部署、自動給網域和 HTTPS，Next.js／Astro／Vite 這類框架幾乎零設定。
• 純靜態頁面：GitHub Pages 最簡單，適合文件、作品集、不需要後端的小工具。
• 容器化服務：Railway、Render、Fly.io 支援直接部署 Dockerfile，需要跑常駐服務或多語言混搭時很方便。
• CI/CD：GitHub Actions 每月有免費運行分鐘數，寫個 workflow 檔案就能在 push 時自動跑測試、自動部署，不需要另外租 CI 主機。

這代表從「寫完程式碼」到「有一個活著的網址可以分享給朋友」，中間可能只隔了一次 git push。

Email（交易信／通知信）

只要有註冊、驗證、密碼重設、通知，就一定會用到寄信，過去要自己搞 SMTP、處理黑名單，現在直接串一個 API 就好。

• Resend：開發者體驗最好的一個，搭配 React Email 可以用 React 元件寫信件樣板，免費額度對個人專案很夠用，是目前個人專案的首選。
• Postmark：低量／小規模免費方案，送達率評價一向不錯。
• AWS SES：免費額度較低，但量大時單價最便宜，適合已經在用 AWS 生態系的專案。

推薦組合：前端已經是 React／Next.js 的話，直接用 Resend＋React Email，信件樣板跟寫 UI 元件的體驗一樣，不用再學一套模板語法。

設計（Design）

不是設計師，也能把介面做得看起來像樣，現在有大量免費資源可以直接拿來用：

• Figma：介面設計、原型稿，免費個人方案就夠一個人做完整個專案。
• shadcn/ui：嚴格說不是元件庫，是可以複製貼上的 Tailwind＋Radix 元件，直接抄進專案再自己改，比從零刻元件快很多。
• Tailwind CSS：utility-first CSS，不用自己想 class 命名，跟 shadcn/ui 幾乎是標配組合。
• Excalidraw：手繪風格畫流程圖、架構圖，免費、線上協作，寫技術文件、畫系統設計圖很好用。
• unDraw／Storyset：免費插畫，可自訂主色，讓空頁面、404 頁不會太乾。
• Google Fonts：免費字型，中英文都有選擇。
• Coolors／Realtime Colors：配色方案產生器，不用自己憑感覺選色碼。
• v0（Vercel）：用文字描述生成 UI 元件程式碼，適合不擅長排版但要生出堪用介面的人。

推薦組合：用 shadcn/ui 當元件底、Coolors 選一組配色、插畫用 unDraw 補空白，一個人也能在很短時間內做出「看起來不是工程師做的」介面。

一個可以直接照抄的免費組合

如果不知道從何選起，這是一個目前很多人在用、幾乎零成本就能跑起來的組合：

前端＋部署：Next.js（或任何框架）→ Vercel
資料庫＋登入＋檔案：Supabase（要做語意搜尋就順手開 pgvector）
快取（選用）：Upstash Redis
Email：Resend ＋ React Email
UI：shadcn/ui ＋ Tailwind CSS
CI：GitHub Actions（跑測試、lint）
網域：先用平台給的 xxx.vercel.app，之後真的要正式上線再買網域
監控（選用）：Sentry 免費層追蹤錯誤

整個流程大概是：GitHub repo 建好 → 接上 Vercel 自動部署 → Supabase 建一個 project 拿到連線字串 → 寫幾支 API 或直接用 Supabase SDK → 要寄信就串 Resend → push 上去就有一個能用的網址。中間完全不用輸入信用卡號。

免費層只適合開發階段，正式上線記得換成付費方案

要先說清楚：以上這些免費層，是拿來做 MVP、練功、放進作品集的最佳起點，不是正式營運的長期方案。真的要開放給不特定使用者用，免費層通常會在幾個地方先出問題：

• 資料庫、Function 閒置一段時間會休眠，第一個請求會有明顯延遲（cold start），使用者會覺得「這網站是不是壞了」。
• Email 免費額度通常是每天／每月固定的一小筆量，行銷信、大量通知信一次就打到上限。
• 儲存空間與流量（egress）都有上限，圖片、影片流量一大就先觸頂。
• 免費層沒有 SLA、沒有正式支援管道，出事只能自己查文件或等社群回覆，不適合「壞了會有人受影響」的服務。
• 部分服務的免費專案有資料保留期限，太久沒有流量甚至會被自動凍結或刪除。

比較完整的應對措施：

• 上線前列一張「額度表」：每個服務的免費額度、超過會怎樣（變慢／擋掉／自動升級扣款），事先寫清楚，不要等出事才知道限制在哪。
• 關鍵路徑優先升級：使用者資料、金流、Email 送達率這幾塊出問題影響最大，優先把它們換成付費方案，其他次要功能可以晚一點再升級。
• 開好用量告警：多數服務後台都有 usage alert，設定好門檻，讓你在快要碰頂時先收到通知，而不是被使用者回報才發現。
• 抓一個保守的使用量估計：抓一個你覺得「有機會發生」的日活躍使用者數，回頭去看各服務對應的付費方案要多少錢，先建立每月固定成本的心理預期，上線後才不會被帳單嚇到。

善用 AI 規劃遷移流程與規格：架構定案要準備上線時，可以直接把目前的技術棧丟給 AI，請它依照實際使用量列出遷移清單，例如：

我目前用 Next.js + Vercel + Supabase（含 pgvector）+ Upstash Redis + Resend。
預估上線後日活躍使用者約 500 人。
請幫我列出正式上線前應該檢查／升級的項目，
包含各服務建議的付費方案、預估月費，以及需要調整的架構或設定。

這種問法比自己一頁一頁翻方案比較表快很多，AI 也能根據你講的實際使用量給出比較具體的建議，而不是泛泛的「要看情況」。

上線前，再請 AI 做一輪資安與效能檢查

架構定案、免費層也規劃好升級路徑之後，正式打開給外部使用者之前，建議至少讓 AI 掃一輪這兩件事，這兩項免費就能做，值得花十分鐘跑一次：

• 資安檢查：API 是否有驗證／授權漏洞、環境變數或金鑰是否外洩到前端、資料庫的存取規則（例如 Supabase 的 RLS）是否正確、使用者輸入是否有做基本驗證與清理、依賴套件是否有已知漏洞。
• 效能檢查：資料庫查詢有沒有明顯的 N+1、該加索引的欄位有沒有加、Serverless Function 的 cold start 是否影響關鍵流程、前端 bundle 大小是否過大、圖片是否有做最佳化。

可以直接請 AI：

請幫我做一次上線前檢查：
1. 資安檢查：找出可能的漏洞、外洩的機密、權限設定問題。
2. 效能檢查：找出明顯的效能瓶頸與可以優化的地方。
針對每個問題說明風險等級，以及具體的修法。

這不是要取代真正的資安／效能專業審查，但對一個人做的 side project 來說，先讓 AI 抓出明顯的漏洞和瓶頸，能先擋掉一大部分上線後才會爆出來的問題。

為什麼值得花時間做一個屬於自己的 App

門檻低到這個程度之後，「沒時間」比「沒錢」更常是真正卡住人的原因，但反過來想：

• 成本趨近於零，代價也趨近於零。 做壞了、沒人用、半途而廢，都不會有實際損失，唯一的成本是花掉的時間，而那些時間本身就是學習。
• 解決自己的小麻煩，是最快的起點。 不需要想出「偉大的產品點子」，先做一個幫自己記帳、算薪水、整理書籤的小工具就好，需求你自己最清楚，也最容易判斷做得好不好用。
• 全端經驗只能靠做出來累積。 看再多文章都不如自己接一次資料庫連線字串、自己被 CORS 卡一次、自己第一次看到部署失敗的 log。這些卡關經驗才是真正的學習曲線。
• 作品比履歷更有說服力。 一個能打開、能操作的網址，比一行「熟悉全端開發」更能說明你會做什麼。

結語

工具已經不是問題了，問題只剩下要不要開始。挑一個你自己生活中會用到的小痛點，用上面任一組合，給自己一個週末的時間做出堪用的版本——不用完美，能動就先上線。剩下的部分，做著做著就會知道下一步要學什麼。