EmDash CMS 自架 Node 部署參考
在你自己的基礎設施上運行 EmDash，從 SQLite 到 PostgreSQL 與物件儲存的漸進架構路徑。
何時該選自架
當限制屬於營運、法規或架構時，選擇自架：
- 資料落地要求嚴格
- 你已在內部運行共用平台服務
- 需要完全掌控執行期、程序模型與網路路徑
- 早期階段想避免受管雲端耦合
自架不會自動比較便宜，通常比較可控。
建議的漸進模型
不要從最高複雜度開始，採分階段推出：
- Node.js + SQLite + 本機檔案儲存
- PostgreSQL 以提升多實例安全與耐久性
- S3 相容物件儲存以提升媒體可攜性
- 程序監督與可觀測性強化
此順序在保留乾淨生產路徑的同時，將遷移衝擊降到最低。
基準架構（階段 1）
單節點生產或早期上線：
- 應用執行期：Node adapter（
standalone） - 資料庫：持久磁碟上的 SQLite 檔案
- 媒體：本機 uploads 目錄
- 反向代理：Nginx 或 Caddy
此設定足以應付低至中等編輯負載與單一執行實例。
# Production build and run
npm install
npm run build
npm run start階段 2 升級準則（遷移至 PostgreSQL）
當出現下列任一情況時升級資料庫：
- 並發寫入競爭變頻繁
- 備份／還原目標超出檔案複製策略
- 需要更安全的多實例部署
在水平擴展應用節點之前先採用 PostgreSQL。在 SQLite 上擴展應用節點會快速帶來營運風險。
儲存策略：本機檔案 vs 物件儲存
本機檔案（由此開始）
適合單實例環境與可預測的儲存成長。
S3 相容物件儲存（規模化時遷移）
在下列情況使用：
- 多個應用實例需要共用媒體存取
- 備份與災難復原必須標準化
- CDN 與邊緣快取策略依賴穩定的物件 URL
私有基礎設施可使用 MinIO 提供 S3 相容行為。
執行期程序與代理基準
程序管理
擇一使用：
- Linux 原生的
systemd服務控制 - 需要程序指標與快速重啟的團隊可用
pm2
反向代理
在代理終止 TLS 並轉發至 Node 應用：
- 保留
Host與X-Forwarded-*標頭 - 設定健康檢查路徑
- 依上傳政策設定 body 大小上限
備份與還原政策
將備份政策視為上線阻擋項，而非上線後任務。
最低基準：
- 依排程建立資料庫快照
- 媒體儲存備份或複寫
- 公開上線前至少做一次還原演練
從未在測試中還原過的備份是傳聞，不是控制措施。
營運就緒檢查清單
生產切換前確認：
- 冷啟動不需手動編輯即可運作
- 應用程式日誌已集中且可搜尋
- 5xx 告警已啟用
- 磁碟用量與儲存成長已監控
- 密鑰輪換流程已文件化
從 Cloudflare 取向設定的遷移備註
若專案最初假設 Cloudflare：
- 從執行期設定移除僅雲端才有的綁定
- 將 D1／R2 轉接器換成 Node 相容的資料庫與儲存轉接器
- 在反向代理後重新驗證驗證與 callback URL
遷移風險多半在環境假設，而非頁面層程式碼。
團隊決策框架
使用此規則：
- 若需要速度與最低營運負擔，偏好受管雲端路徑
- 若需要掌控與現有基礎設施整合，偏好自架路徑
每個環境選一種預設路徑。混合部署可行，但會增加認知負載與支援負擔。