Reflections on content management systems (CMS)

Published: 2026-08-19

In my current quest to decouple systems where I can, I fell down the rabbit hole searching for the perfect content management system (CMS) to run this blog. After a few cycles of trial and error, trying out different solutions, I think I landed on the right tool for my needs.

Where I’m coming from

I love Astro! And I love it’s content layer abstraction. It does an amazing job rendering Markdown and enforcing type safety via defining content schemas. But, what I don’t like is that the default tools steer your towards working with Markdown files that live in the repo. Using this method, content is tightly coupled with the source code. It’s convenient for building locally, but creates a couple of issues when coding in public:

You can’t hide your in-progress posts.
Images and other public assets live in your git hosting platform.

Ultimately, I wanted a more flexible solution that let me keep my code public, keep the content private, and offer a similar experience to the niceties that the Astro content provides.

Payload CMS

When evaluating my requirements, Payload CMS ended up catching my interest because of it unique architecture. Unlike some drag-and-drop alternatives, Payload utilizes a code-first, declarative approach for content configuration, allowing developers full control with the potential for massive extensibility. It was something I could craft and mold to my liking!

Some major advantages include:

A good plugin system for extending the base instance: I ended up installing some great image preprocessing tools to cut down image storage sizes on upload.
S3 and PostgreSQL Tooling: Out of the box, Payload CMS provides you with easy to configure plugins for backing assets with S3 storage and data with a PostgreSQL database.
Virtual fields & API Hooks: Payload CMS’s way of letting you preprocess data for API responses, without storing results in the database.

All of this is cool, but other solutions offer theses as well, I think the critical advantage Payload CMS has lies in its technical structure. Defining collections using Typescript was very much like defining an Astro’s content collection schemas. Everything was declarative, any types generated by Payload could be shared with the Astro frontend, and changes and configurations made in development could seamlessly persist in production.

Final thoughts

Deciding to use Payload has been a great joy, I guess this feeling of satisfaction also stems in part from the control and ownership over the tool that I am using. I’m not constrained by a predefined set of features, and If I need to add a new feature, I’ve got a good set of tools to make it happen.

Have you tried Payload CMS? In a later post I’ll go over the technical bits of how you can get Payload to integrate with the Astro content layer!