Headless CMS’s 100

What is a Headless CMS?

A “Headless CMS” is very simply a detached admin panel who’s responsibility is to manage a database of authored information and perhaps global configuration, and that’s about it. It has no front end layer, no template engine, no nothing. It exists and operates entirely on it’s own as a tool to manage your data with an interface for your content authors. admins, and moderators.

CMS != Horseman. But only kinda.

A second though admittedly optional responsibility to supply a good API to access that data in a managed way. This is optional because having apps direct query the database the CMS manages is also a possibility (Though probably not as desirable). A pretty common pattern is to have a 1, 2, punch combo of a Headless CMS and an individually scalable microservice.

Monolithic CMS systems like WordPress, Drupal, Joomla, and the 75 million others just like it out there, couple the admin and the front end together in a tightly bound walled garden of a singular deployable ecosystem. Though this system has it’s pro’s and con’s along with anything else, our “con” here is that this pattern tends to get huge, unweildy, and difficult to update without breaking something.

Why would I want a Headless CMS? sounds like a chore.

What if you didn’t want the public at large to access your admin panel at all? Sure you could make the admin url something bizaar. However “Security through Obfuscation” is a practice best curbstomped as soon as you can. Someone will always find it.

Having a detached CMS allows you to place it wherever you want. Host it off your desktop, put it up in Heroku, hide it behind a firewall, the options are endless and the security implications of not allowing the public at large to ever get to it in the first place is a great step to making sure no one cracks a contributors password and starts messing with your site data.

A huge benefit is having the authored data made available by an API layer. This means you’re in much better control of the amount of connections to your database, and much easier to scale when the traffic gets heavy.

But here’s a huge beneficial plus: Multiple THINGS can use this data.


Your authored data can be accessed by several sources at once.

Imagine every time you’ve written a website, where someone on the team has asked “can I get this data?”. They’re not looking to scrape rendered HTML, they’re looking for JSON or XML with the raw data. So you set to work writing a bespoke API for this need. Imagine that need already fulfilled by the sheer virtue of how you built the project in the first place?

Imaging for a moment, that your data not only powers your main site’s presentation, but is capable of powering other sites on your network with choice pieces of data? Licening third parties to use your data via this api?

What makes a good Headless CMS?

There’s no wrong way to build a Headless CMS. As long as you can author content from it, and something else can separately read that data somehow, you’ve got yourself a winner.

But what if you’re in the market for good Headless CMS off the shelf? What do you opt to go with?

Lucky for you, there exists an entire site dedicated to finding some Self-Hosted and Cloud-Hosted Headless CMS solutions, may I present to you https://headlesscms.org

Your one stop shop for content management, minus the overHEAD!

Many of these projects allow you define content with JSON, to which the CMS will store new records using that schema.

Others provide a CCK (Content Creation Kit) experience where you use the admin UI to construct new Content Type’s by creating fields and assigning common widgets to handle the input.

Some store their content in a database.

Some store their content in markdown files.

Some store their data in json blobs on the filesystem.

Some provide a RESTful API

Some provide a GraphQL endpoint

Or.. y’know, a Reese’s. Sadly there’s a lack of Gif’s with that slogan 🙁

In Conclusion

Pick one. Build one. Headless CMS’s are the way of the future. Many many more people, companies, everything are opting for a content management system that’s decoupled from their websites and apps.

Even WordPress has started recognizing that providing a rich API is really the only way to stay in the game. More on that later!

Until then,