Why This Site Is Now Headless

This site has changed substantially behind the scenes. It is now a headless, Git-first site rather than a traditional WordPress site with an in-browser editor.

The main reason is editorial workflow. In the age of AI, the classical CMS editor is no longer where much of the work happens. I now use AI in different ways: sometimes only for spelling and grammar, often to check whether a text is understandable, and sometimes to turn facts I provide into a first draft. I review the result in all cases.

This post itself is somewhere in the middle: editorially directed by me, with AI helping with style and expansion.

The editor is now the workflow

A Git-based workflow fits this much better. The actual editor is the AI-agent session, with the article stored as a reviewable change in the repository. That gives me a clear history of what changed, a more predictable publishing process, and a good basis for checks before an article is published.

It also makes it possible to explore new kinds of posts. For example, I may write about recent activity or findings from data, where AI can help turn validated source material into a readable article. Whether I will use that more broadly remains an experiment. The important point is that the source material and the final decision remain mine.

Less public attack surface

There is also a security reason. A traditional CMS is a capable application exposed to the internet, and that capability comes with attack surface: logins, plugins, themes, databases, and administration interfaces all need ongoing attention. In an AI-driven world, keeping the public attack surface as small and simple as practical matters even more.

The new site is deliberately much simpler. Content is maintained in Git, the public result is built as a static site, and DigitalOcean App Platform runs the deployed application. App Platform can deploy from a Git repository or a container image while taking care of the underlying platform. For this site, that removes a substantial amount of operational work.

A straightforward publishing process

The workflow is straightforward: write or revise content in Git, review the change, run automated quality checks, build an immutable deployment image, and deploy that exact version. I am continuing to automate more of the checks around deployment, so that an article update is not merely published but demonstrably healthy afterwards.

I genuinely like this approach. As an rsyslog maintainer, I would rather spend my limited time on the project and its users than on routine site management. DigitalOcean App Platform does not remove responsibility, but it takes enough of the platform work off my hands that this is realistic. I think the same can be valuable for startups and small teams: they can concentrate on what they are building without first having to assemble a large operations and security function.

The new setup has other benefits as well. Side visuals are easier to handle well, cookie handling is improved, and the site gives me better control over how content and media are presented.

This site is the first experiment. If it continues to work well, I expect rsyslog to follow later.

Thank you, DigitalOcean

Finally, my thanks to DigitalOcean and its Open Source Sponsorship program. Their support helps make this experiment possible and lowers the practical barrier to trying a more secure and maintainable publishing model. I am grateful for that. #DOforOpenSource

AI use: AI-assisted; reviewed by me.