>internalkernel Work with me
← build-log

Killing WordPress: the agent is the admin panel

· #build-log#infrastructure#web

Entry zero said this site has no CMS, no admin panel, and no database, then left it there. This is the entry that explains the decision — why the page you’re reading is published the way it is, and why a fleet of other sites is being moved onto the same path.

The perception tax

“Just use WordPress” is the default answer for putting a site online, and for a lot of sites it’s still the right one. But the default carries a cost that doesn’t show up until later. A WordPress site isn’t something you build once; it’s something you maintain forever. Core updates, plugin updates, the plugin that breaks on the update, the PHP version a theme pins you to, the security surface of every plugin you added just to get one feature. A brochure site that hasn’t changed in a year still demands attention, because the platform underneath it keeps moving whether the content does or not.

Call it the perception tax: “just use WordPress” looks free and quietly becomes a standing maintenance line item. For a site where one person — me — is the only editor, paying that tax buys nothing. There’s no editorial team that needs a familiar dashboard. There’s just content, and the overhead wrapped around it.

The decision

So internalkernel.com doesn’t run on a CMS at all. It’s a static site: Astro and Tailwind, content authored as markdown in a git repository, built to plain HTML.

A few alternatives were genuinely on the table:

  • Ghost — a lovely publishing platform, but it’s a running Node + MySQL service to host and patch (the maintenance I’m trying to delete), its newsletter is wired to one specific mail provider, and its theming layer constrains the design more than I wanted.
  • Next.js — capable, but heavier than a content site needs. For a build-log, Astro’s zero-JavaScript-by-default output and first-class markdown handling fit better than shipping a React runtime just to render prose.
  • WordPress — the perception tax above.

The agent is the admin panel

Here’s the part that matters most for this particular site. There is no wp-admin. No login, no dashboard, no “new post” button. The publishing interface is the repository.

When there’s a new entry — this one included — the agent writes the markdown, commits it, and pushes. Continuous integration builds the site; the edge host deploys it. That’s the entire pipeline:

edit markdown  →  git commit  →  CI build  →  deploy to the edge

This isn’t a gimmick to make a blog sound clever. It’s the reason the stack was chosen. A CMS assumes a human in a browser is the editor. When the editor is an agent, a CMS is friction — a GUI wrapped around content the agent would rather address as files. Text in a repo is the native interface.

Cloudflare Pages for everything

The static build is served from the edge — every site in the practice, this one included. The interesting decision there isn’t “use a CDN.” It’s where the work lives.

There’s a server in this story: a VPS that runs the agent fleet and its memory. The temptation is to serve the websites from it too — it’s right there. The decision was the opposite: serve nothing from it. Move all web-serving load — CPU, RAM, and bandwidth, not just disk — off the box entirely and onto the edge.

The payoff is clean separation:

  • The box stays dedicated to what only it can do: run the agents and hold the memory.
  • The sites stay up even when the box reboots — they don’t live on it.
  • Static files on a global edge are fast everywhere by default, and the edge absorbs traffic with no server to scale and nothing in the request path to patch on a Tuesday.

What “owned infrastructure” actually means

This reframes a claim worth being careful about. A build-log like this is supposed to draw its credibility from running on owned infrastructure — yet the HTML is served from someone else’s edge network. Contradiction?

No, because the owned infrastructure was never the web host. It’s the operator desk: the OS on the VPS, the agent fleet, the memory layer, the tooling that turns an intent into a committed, built, deployed page. That’s the workshop. The website is its output — the artifact the workshop produces and ships to the edge.

Decapitation

internalkernel.com is greenfield — there was never a WordPress install behind it. But most of the fleet wasn’t. So the same decision becomes a migration plan, and the plan has a blunt name: decapitation.

For a site where the client is the editor and wants a familiar dashboard, WordPress stays — either as-is, or as a headless content source behind a static front end. That’s a real and good fit, and it isn’t going anywhere.

But for a site where I’m the sole editor — a small brochure site on an aging theme, say, pinned to an old PHP version it can’t safely leave — there’s no reason to keep a database and a PHP runtime alive just to serve a handful of pages that rarely change. So the content gets extracted to markdown once, rebuilt on the static stack, and then WordPress is removed. Not disabled — deleted. No PHP, no database, no plugins, nothing left to patch. The box gets that much lighter.

Honest close

Because internalkernel.com had no WordPress to kill, it isn’t really the first decapitation — it’s the reference build. It’s where the static stack, the agent publishing pipeline, and the edge deployment got proven on a site that matters, so the fleet migration becomes reuse instead of invention. The same pipeline that shipped this post is the one that rebuilds the next site off WordPress.

That migration is in progress, not finished. One site is greenfield and live (this one). Several are still on WordPress, queued by how much the old platform is costing them. The honest status: reference implementation done, fleet conversion underway. I’ll log the first real decapitation here when it ships.