Headless CMS: Self Hosted or PaaS?

Wikipedia (that bastion of absolute truth) defines a headless CMS as:

Back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device. The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository).

The first question in using a headless CMS (or any technology solution for that matter) should be 'why?'.

What problem am I looking to solve and how will this platform solve that problem? In my opinion, a headless CMS is a good fit for instances where content is consumed by multiple channels: native apps, third-party content consumers or IoT devices.

That said, I don't believe it needs to be an all or nothing solution. A hybrid approach can definitely strike a balance between both concepts.

I’ve never bought into the idea that a headless CMS gives you less tech debt. It’s just not true, that debt simply goes somewhere else. I also think that going entirely headless; you throw the baby out with the bath water. As an example: not using the front end templating of Statamic CMS means you’d lose the awesome live preview functionality that they have built right into their platform and as a publisher, that’s huge.

If you're committing to implementing a headless CMS, your next decision is whether to self-host/develop or use a platform as a service (PaaS). Most modern, self-hosted CMS platforms like Statamic, Craft, & Drupal have the tools you need to expose your content via an API. However, the PaaS model is gaining popularity. Some popular services include Contentful, Prismic, and Butter CMS.

Seek to understand the problem at hand. Speak with your content folks to understand the content they’re publishing and the relationships between different content types.

- Me last week

When to use a CMS as a service

You may opt to use a CMS PaaS if you have concerns over: maintaining security of a CMS application, have scaling concerns (you most likely don't) or your content needs are minimal (like just needing a blog for your app).

When you opt to self-host/develop you have next to almost no restrictions but that's not always the case with a third-party platform. From experience, they have restrictions on:

• number of users/authors
• storage space
• user roles
• number of content types
• number of content pieces
• localization
• API call limits
• stack integrations
• data portability

When to use a self-hosted headless CMS

My biased, worked with a ton of CMS platforms in my career, answer/opinion would be: all. the. time :)

I smile in saying that but I honestly haven’t come across an instance yet where, given the choice, I’d choose a PaaS CMS over a self-hosted CMS.

From a developer standpoint, I found myself more frustrated than normal during development. In one instance, I wasn’t able to grab all content types for a single author. Another instance where documentation for the API call was off slightly and so wasted an hour or so before figuring out that I wasn’t the issue (which is rare).

Having an API is a great start but if you’re fighting with it or hitting limitations, it can become a frustration and blocker (unless you have some enterprise agreement with instant support). With a self-hosted approach, you get to define and extend that API on your terms. Want GraphQL perfect! If traditional REST is more your thing, have at it. The choice is up to you.

With a PaaS you have no control over any of that, it’s their way or the highway. Sure, with some creative JavaScript you can work around it but as someone who has worked between a myriad of CMS platforms, it feels like a sub-optimal approach from the perspective of the developer and the content author.

I can normally get a solid amount of work done whilst travelling by train with even the spottiest Internet connection. If you have a hosted CMS, that can be more problematic. Self-hosted you can run locally and the callbacks are more reliable.

But what should I/we go for, Steven?

See above. Like everything, it depends. Seek to understand the problem at hand. Speak with your content folks to understand the content they’re publishing and the relationships between different content types. Most of the PaaS CMS tools have base level instances you can spin up to get a feel for how they allow content modelling. Read their docs, make sure that it will can integrate with your existing stack. Have an understanding of the learning curve that might be involved during integration.

If you have concerns around self-hosting a CMS headless or otherwise, then finding a partner, like Zaengle would alleviate that - we would love to speak with you. Handing off that responsibility to a vendor is the same as picking a PaaS but you’ll have greater power and less hassle in trying to migrate to something more in tune with your specific requirements further down the line.