管好你自己，把資料主權拿回自己手裡，全新部落格的心路歷程

搬家，是這幾年部落客最沉重的心路歷程。

雖然我是個佛系更新部落格的人，但對部落格的感情其實還挺深的。大學期間寫了不少成長週記跟踩坑紀錄，畢業後被一堆事纏身，反而什麼都沒寫上去。我自認文筆沒那麼好，但回頭看那些 2019 年寫 Rails、裝雙系統、修 Oracle 的文章，還是會覺得：這些東西是我的，不能就這樣不見。

這篇記錄一下這個部落格搬了幾次家，以及最後為什麼決定「什麼都自己管」。

# 第一次搬家：Hexo 時代

最早的部落格是 Hexo，Markdown 寫一寫、hexo deploy 推上 GitHub Pages，免費又簡單。那時候還寫過一篇〈用 Hexo 免費製作一個 blog〉，後來又加了 utterances 做留言、升級 V5 踩了一堆坑。

Hexo 最大的好處是：文章就是一堆 Markdown 檔，放在我自己的 repo 裡。要搬去哪都行。

壞處是，它真的就只是一堆檔案。想要後台、想要排程、想要多語系，就得自己硬幹。

2025 年重新開站的時候，我被「正經的 CMS」誘惑了。前台用 SvelteKit 跑在 Cloudflare 上，後台接 PayloadCMS，資料放在 Turso。

Payload 很好用，後台漂亮、欄位彈性，但用了一陣子之後，越來越不對勁：

這就是我說的資料主權問題。資料當然還是「我的」，但它被包在一層又一層的抽象裡。哪天 Payload 改版、Turso 改方案，我就得跟著跑。

2026 年 6 月，我把 Payload 整個砍了。現在的架構簡單到有點好笑：

一個 R2 bucket 就是整個「資料庫」：index.json 是文章列表，content/.md 是內文，media/ 放圖片
後台是自己用 Elysia + Svelte 寫的小工具，跑在 cms.kidneyweakx.com，前面擋 Cloudflare Access，只有我登得進去
前台的 Worker 只拿得到 R2 的唯讀權限。在型別上就只開放 get / head / list，runtime 也只轉發這三個方法，就算哪天前台被打穿，也改不了任何一篇文章

搬家的時候寫了一支一次性的匯入腳本，把 Turso 裡的文章全部轉成 Markdown 丟進 R2。轉完那一刻，看到每篇文章又變回一個 .md 檔，有種把東西從當鋪贖回來的感覺，資料自主果然是很關鍵的啊。

這陣子在做 Solid(ar)ity ↗，一個自己掌握鑰匙的身份頁和名片 app，我們團隊有一個原則：「公司倒了，機制還在」。資料放在使用者自己的裝置跟雲端，驗證全部在用戶端跑，就算專案明天消失，每一張卡、每一個證明都要還能驗，甚至是全部都要能繼續跑。

做著做著就回頭看自己的部落格：我連自己的文章都沒做到這件事，好像有點說不過去，身為一個 cypherpunk，怎麼甘於自己那麼廢物。

所以這個部落格現在的原則是：

既然文章都是 Markdown，順手也做了給 AI 讀的版本：每篇文章後面加 .md 就能拿到原始 Markdown，另外還有 llms.txt 跟 RSS。現在越來越多人是透過 AI 找答案，與其讓爬蟲去啃一堆 HTML，不如直接給它乾淨的原文。不過這個方案是很後期才搞出來的。

說到底，「資料主權」聽起來很大，其實就是一件很小的事：你寫的東西，你要知道它放在哪、長什麼樣子、怎麼帶走。

搬了三次家，最後發現最好的架構，跟 2019 年的 Hexo 差不多：一堆 Markdown 檔。只是現在多了一個好用的後台，跟一道 Access 門鎖。

繞了一大圈，原來 KISS 才是正確的。（又來了 XDD）