Moving out of the house I built

This site doesn’t run on Concrete CMS anymore.

That’s a strange sentence for me to write. When we first open sourced Concrete in 2008, I couldn’t wait to use it on my own website. This blog has run on it in one form or another ever since. (At least for a while: after 2017, I mostly let the place atrophy. For crying out loud – I never even put it behind SSL!)

It made sense: at its height Concrete CMS (then named concrete5 – yep, that’s right, with a lowercase “c”) powered hundreds of thousands of websites of many sizes, across many verticals. We needed to eat our own dog food! When something broke in Concrete, I often found out here first.

But today, the site is a folder of Markdown files, built into static HTML and served from Cloudflare. The CMS I write in is one I built myself, for exactly one user.

It’s bittersweet.

This isn’t a breakup

I want to get this out of the way first: if you’re running a content-heavy site with a bunch of people who need to manage it, Concrete CMS is still the tool I’d reach for. Lots of pages, lots of editors, different people allowed to touch different things: that’s exactly the job it was built to do. The original vision of “see a typo, fix a typo” right from the page? It still delivers on that, and we are privileged to still have a group of extremely passionate, knowledgeable, prolific and talented developers working with our open source project.

But my blog has none of those problems. It has one author. I’m a developer, and happiest in a text editor. Most of what Concrete is good at, I wasn’t using. At PortlandLabs we work hard to ensure our tech stack is kept up to date, but I definitely did not apply the same rigor to my personal DigitalOcean droplet: as it became annoying to keep everything updated, I let that friction keep me from posting, and it wasn’t long before my blog was a ghost town.

What I wanted instead

Plain files

Every post is a Markdown file, with its images in the same folder. The whole site lives in git. It sounds small, but it changes what owning the site feels like. I can search the whole archive with BBEdit. And if every tool I use today goes away, I’ve still got a folder of text files that pretty much any computer can open. And metadata can just live in the post alongside the content:

---
title: "Moving out of the house I built"
date: 2026-10-02
dek: "I co-founded Concrete CMS. I'm still its core team leader. But this blog doesn't run on it anymore. Does that feel strange? You bet."
heroAlt: "Brown wooden house surrounded by green trees during daytime"
heroCredit:
  name: "Josh Hild"
  url: "https://unsplash.com/@joshhild?utm_source=andrewembler_studio&utm_mediu>
  source: "Unsplash"
  sourceUrl: "https://unsplash.com/photos/brown-wooden-house-surrounded-by-gree>
series: "rebuilding-this-site"
seriesPart: 1
draft: true

No server to babysit

A static site has no PHP to update or database to back up. Static HTML will always be the fastest, most secure way to host a website. We employ talented DevOps folks to do this; it was never something I was interested in or particularly skilled at. I’m glad I can now delegate that problem to Cloudflare!

A modern, elegant experience

This last part is the toughest part to admit: my blog had grown stale, and I didn’t really want to improve it. I had ideas about a design that adapted to the colors present in imagery, but I couldn’t justify the amount of time it would take to achieve it. Yes, you can (and always have been able to) build anything in Concrete, but at some point the idea of clicking on images and micro managing content just for a post struck me as just too fiddly. For a personal blog, it was too much management and not enough content.

A CMS built for one person

This is the part I’m most excited about.

Every general-purpose CMS has to make compromises. Concrete makes them on purpose, and I’ve spent a long time defending those choices. A CMS has to work for a church, for a university, for a law firm, and for someone’s band. Concrete has always been powerful and flexible, because it had to be.

But mine doesn’t. It does what I want and nothing else. No, it’s definitely not built in a vacuum: this site runs on the great work done by Astro, alongside a custom CMS named… you know what? It doesn’t even have a name! I think we’re finally post-product, here.

When I want a new feature, I add it. When I stop using one, I delete it. There are no packages to update, and no users dependent on something I must decide I no longer want to support. The only person I have to argue with is me (and I usually lose.)

For years, I’ve been building software meant to work for everyone. It’s an interesting feeling to build something that only has to work for me.

The weird part

I’ve spent 20 years telling people that a good CMS lets you focus on content instead of infrastructure. And here I am, having built my own infrastructure so I could focus on content.

The right tool depends on who’s holding it. For an organization with editors, a CMS like Concrete takes away a pile of problems. For one developer with a blog, some of the problems were the CMS itself. Sometimes all you need is a folder full of files.

What’s next

If you’re reading this, you can safely assume that I succeeded!

If you’re still using Concrete CMS – thank you! Don’t forget to update to 9.5.5 next week! Concrete powered this site for a long time, and I’m grateful for that. It just doesn’t need to anymore.