--- title: "Manage It Yourself: Taking Back My Data Sovereignty, and the Road to a Brand-New Blog" description: "Moving house has been the heaviest ordeal for bloggers these past few years." author: "kidneyweakx" published: 2025-12-31T00:00:00.000Z updated: 2026-10-29T11:27:12.629Z lang: en tags: ["blog", "cloudflare", "隨筆"] canonical: https://kidneyweakx.com/blog/take-back-your-data-sovereignty?lang=en alternate_zh_tw: https://kidneyweakx.com/blog/take-back-your-data-sovereignty.md alternate_ja: https://kidneyweakx.com/blog/take-back-your-data-sovereignty.md?lang=ja --- # Manage It Yourself: Taking Back My Data Sovereignty, and the Road to a Brand-New Blog > Moving house has been the heaviest ordeal for bloggers these past few years. I'm the kind of blogger who updates whenever the mood strikes, but I'm actually pretty attached to my blog. In college I wrote plenty of weekly growth logs and notes on the pitfalls I fell into; after graduating I got buried in a pile of other things and ended up writing nothing at all. I don't think I'm much of a writer, but looking back at those 2019 posts about writing Rails, setting up dual boot, and fixing Oracle, I still feel: **this stuff is mine, and I can't just let it disappear**. This post records how many times this blog has moved, and why I finally decided to "manage everything myself."
## First move: the Hexo era The earliest version of the blog was Hexo: write some Markdown, `hexo deploy` it to GitHub Pages, free and simple. Back then I even wrote a post called "Making a Free Blog with Hexo," and later added utterances for comments and stepped on a whole bunch of rakes upgrading to V5. Hexo's biggest upside: **the posts are just a bunch of Markdown files sitting in my own repo**. I can take them anywhere. The downside is that it really is just a bunch of files. Want an admin panel, scheduled posts, multiple languages? You have to hack it all together yourself. ## Second move: the temptation of a CMS When I relaunched the site in 2025, I was seduced by a "proper CMS." Frontend in SvelteKit running on Cloudflare, backend hooked up to PayloadCMS, data stored in Turso.
Payload is great to use: nice admin UI, flexible fields. But after a while, things started feeling more and more off: * For a blog updated once or twice a month, I was keeping a CMS service and a database alive * Posts became rows in a database, **no longer files I could actually read** * If I wanted to back up or move, I'd first have to understand its schema and then write an export script That's the data sovereignty problem I'm talking about. The data is still "mine," of course, but it's wrapped in layer after layer of abstraction. The day Payload ships a new version or Turso changes its plans, I have to scramble along with them. ## Third move: tearing out the CMS In June 2026, I ripped out Payload entirely. The current architecture is almost comically simple: * One R2 bucket is the entire "database": `index.json` is the post list, `content/.md` holds the post bodies, `media/` holds the images * The admin is a little tool I wrote myself with Elysia + Svelte, running at `cms.kidneyweakx.com` behind Cloudflare Access, so I'm the only one who can log in * The frontend Worker **only gets read-only access to R2**. At the type level it only exposes `get` / `head` / `list`, and at runtime it only forwards those three methods, so even if the frontend gets breached someday, nobody can change a single post For the move I wrote a one-off import script that converted every post in Turso into Markdown and dropped it into R2. The moment it finished and I saw every post turned back into a `.md` file, **it felt like redeeming my stuff from a pawnshop. Owning your own data really does matter**.
## Why do I care so much? Lately I've been working on [Solid(ar)ity](https://github.com/p2p-solidarity/solidarity), an identity page and business card app where you hold your own keys. Our team has one principle: **"If the company dies, the mechanism lives on."** Data lives on users' own devices and cloud, all verification runs client-side, and even if the project vanished tomorrow, every card and every proof should still verify, and ideally everything should keep running. Building that made me take a hard look at my own blog: I hadn't even pulled this off for my own posts, which is kind of hard to justify. As a cypherpunk, how could I settle for being such a slacker? So the principles for this blog are now: 1. **Posts are files, not rows**. Open R2 and you can read them; if I want to move, I pack up the whole thing and go 2. **There's only one way in for writes**. Only the admin can write; the frontend is read-only forever 3. **Don't depend on any service I don't have to**. No DB, no third-party CMS. If Cloudflare ever becomes unusable, the Markdown can live on in any static site generator ## The version for AI Since all the posts are Markdown anyway, I also made a version for AI to read: append `.md` to any post's URL to get the raw Markdown, and there's also `llms.txt` and RSS. More and more people find answers through AI these days, so rather than letting crawlers chew through a pile of HTML, why not just hand them the clean original. That said, this part only came together pretty late.
## Manage it yourself At the end of the day, "data sovereignty" sounds grand, but it's really a small thing: **for whatever you write, you should know where it lives, what it looks like, and how to take it with you**. After moving three times, I found that the best architecture is pretty much the same as Hexo in 2019: a pile of Markdown files. Just with a nice admin panel now, and an Access lock on the front door. After going all the way around, **turns out KISS was right all along**. (Here we go again XDD)