Blog Migration

I’ve been chasing a small, stubborn problem: I learn something worth writing down most days, but I publish far less often than that. I wanted a setup that made it easy to take a daily learning and get it posted regularly — so it’s there for my own reference later, and useful to anyone working through the same thing.

The platform I was on was sleek and convenient. It handled the patching, the visuals looked good, and for a long time that was the trade I wanted: pay for convenience, skip the upkeep. But when I went to automate my publishing the way I had in mind, I hit a wall. That was the nudge to spread my wings and build something I owned end to end.

Here’s what I built, and why I made the calls I made. If you’ve felt the same pull — wanting to publish more often, with less friction — some of this should carry over.

Why I didn’t just switch platforms

The easy move was to hop to another hosted platform. But I work in security, and before chasing features I ask a quieter question: what am I signing up to defend?

A traditional CMS is a living application. It runs code on a server, talks to a database, and leans on plugins — each one someone else’s code running inside my site. That’s a lot of capability, but it’s also a lot of attack surface, and a standing job to patch all of it. For a site whose only job is to show words and pictures, that’s a lot of moving parts to keep safe.

So I asked a different question: what’s the least machinery that can do this job? That’s usually where I find the best wins — the simple options nobody bothers to name.

The answer: a site that’s just files

The least machinery turns out to be almost none. My blog is now a folder of plain HTML, built ahead of time and served as static files. There’s no application server waiting for requests, no database to attack, no plugins to compromise. The pages you’re reading were built once and handed to you.

It runs on a few standard cloud pieces: object storage holds the files, a CDN serves them over HTTPS, and a small build step turns my Markdown into the finished site whenever the content changes. The storage bucket is private — only the CDN can read it — so there’s no public door to rattle.

The security here is good, and not because I did anything clever. It’s good because there’s so little to attack. No database, no SQL injection. No plugins, no third-party code on my site. No server, nothing to patch. The most reliable way off the patching treadmill is to never get on it.

The workflow I was after

This is the part I care about most, because it’s the reason I moved. The endpoint is the foundation: a small, locked-down API that takes a post, drops it into storage, and kicks off a rebuild. It’s protected by a key I generate, rotate, and revoke, and I hold the only copy.

What it unlocks is the part I actually wanted. I started by naming the workflow worth improving — turning a daily learning into a published post — and broke it into its parts: capture the idea, draft it, check the voice, handle images and links, publish, and confirm it’s live. Most of those steps are mechanical, so I handed them to an agent. It drafts from a rough note, formats the post, uploads any images, calls the publish API, and checks that the page renders.

I stay in the loop at the one step that needs my judgment — reading the draft and making sure it still sounds like me — and let the agent run the rest. That’s the level of control I want: a person where it counts, automation where it doesn’t. The point isn’t to take myself out of the writing; it’s to clear away everything around the writing, so posting a learning is a short review instead of a chore. That’s what makes “regularly” realistic.

Where the rubber meets the road

I won’t pretend this is free. I gave up the managed convenience I’d been paying for, and the all-in-one dashboard with it. Things that used to be a toggle — comments, memberships, interactive widgets — are now a decision each time: is this worth adding a moving part back?

For me, that’s fine. A static site needs so little upkeep that the trade was easy, and now every bit of complexity has to earn its place by being something I actually want, instead of something that showed up by default and became mine to maintain.

The move wasn’t zero work either. I had to bring over the back catalog — a modest one, about ten posts and their images — and keep the old URLs working so the links still resolve. That’s a one-time cost, and what I got for it is durability: my content is plain Markdown and ordinary files. If I want to move again, I can.

A few principles that carry over

Strip away the specifics and a few ideas here apply well beyond blogs.

Attack surface is a budget, and “default on” spends it for you. Features you never asked for are still yours to defend. Cutting capability you don’t need is a real security move, and an underrated one.

Owning the boring layer beats renting the shiny one. Plain files and a key you control will outlast any vendor’s roadmap.

The cheapest fix is often the one nobody named yet. This started because I wanted to automate one small thing, couldn’t, and asked whether that wall pointed at something bigger. It did. Most of the wins I’ve found in my career started the same way — as something small that everyone else had learned to ignore.

I rebuilt my blog to make publishing easy enough that I’d actually do it regularly. I came away with more than that: a site I understand completely, can defend without much effort, and can take with me anytime. For a blog about making security less esoteric — and one I want to keep feeding with what I learn — that fits.