Say hi to Carrier – the new headless CMS at

Germany’s leading people news website (30m+ visits/month) is now powered by Carrier, a full featured headless publishing setup with a strong focus on distribution and rendering. This approach called “decoupled” or “headless” enables us to handle content curation & creation independent of content packaging, distribution, syndication, placements etc.

Our editor’s workspace Thunder (Burda’s own Drupal Distribution) is providing the created content via a REST/JSON API and is not involved in any kind of rendering, placements, caching etc. This part is handled by a Custom Java Application called Cockpit. This custom application also enables the editor to send push notifications, manage placements on the website using a micro service called Pilot and many other features.

Carrier components: CMS, Cockpit, Pilot & Rendering


Benefits of a headless CMS setup

There are a couple of good reasons to go headless:

  • Focus on the next business opportunities & challenges
    You need flexibility and clear abstraction to reach your goals, as websites turn into products instead of “CMS projects”.
  • Micro service  architecture with Docker & CI/CD
    Carrier consists of micro services handling different parts of the system. We can now enable/disable/upgrade certain parts without touching the entire system.
  • Simplification of output format management
    This is possible due to the abstraction of the well-structured content and output. Think of using content for e.g. chatbots or Amazon Echo.
  • Substantial frontend rendering performance increase
    The entire markup is now under our control and not a wild mix of script, markup and styling blocks created by multiple modules.
  • Simplified caching layers and no more purging pain
    Our simple caching rules: Pages = 1min, Images + Assets = 8hrs. Simplest Akamai config ever. That’s all, no more Varnish/Purging/Expiry Management.
  • Subjectively: Increase of talent in the team
    The stack is broader and it’s just offering a mix of “sexier” technologies.
  • More stable CMS
    Drupal is focused on content creation/curation and providing this data with a simple REST API just runs smoother than one handling tons of stuff.


Why did you go headless?

Short answer: We’ve been tired of the traditional CMS experience and it’s tradeoffs. When looking for alternatives, the PM and CTO stumbled upon articles on the Washington Post Product BlogSmashing and Vox, got inspired and decided should follow this approach as well.

Long answer: The traditional way of developing websites feels just not right in a world with a growing number of distribution channels, formats etc. A lack of flexibility, poor performance and the missing level of abstraction (“The Story” should be just kept independent of any other aspect) are key topics. And not to forget the pain of having tons of modules in your setup for simple tasks. Want feature A? Sure, it just depends on module B, C with C only working with CMS version x. Plus the need to maintain rather complex caching setups as otherwise your CMS will become unresponsive pretty soon.

What about image management & rendering?

We’re running multiple instances of the amazing Thumbor. Thumbor gets passed information set by the editor in the CMS (Focal Point) to have the correct center for resizing.

What about the performance?

Data sent from the CMS is stored in Redis with maintained relations. Based on that, we can render even complex articles in approx 15 msec.

How is the frontend managed, which libraries do you use?

Our stack is pretty basic – Bootstrap, some custom scripts and a really powerful Google Tag Manager setup. Actually our entire dynamic frontend is managed by GTM including ad rendering, tracking, Recommendation widgets etc. Say goodbye to modules eating attention for tasks which easily can be covered in a few lines JavaScript and a datalayer property.

What about menus, top articles etc? How are they managed?

We’ve cut the pages into parts rendered as individual pieces and stuck them together using good old Apache SSI. The same applies to e.g. the header, all fully managed using the CMS and will be sent to Cockpit via API. Top articles are fetched from Google Analytics on a regular basis, same for trending.

What kind of drawbacks to be expected?

It’s getting complex. You need senior people who have been working with rather complex setups, you need data contracts (using e.g. swagger) and solid end2end tests (read: Selenium, cypress) to make sure the data that is entered at the CMS is properly rendered in all output formats.

What happens exactly when the editor hits the “Publish” button?

Our CMS will ping Cockpit, Cockpit will fetch the data using a REST API, render the article in 8+ formats (web, amp, FB IA, syndication partners, …) and trigger renderings of connected objects (e.g. an image is updated which is part of 10 image galleries which is part of 20 articles). Additionally, updates of various feeds are triggered (Sitemaps, RSS Feeds, Feeds for the App, syndication feeds, Newsletter systems etc). So there’s quite a few things are going on 🙂

How do you deploy a new version?

Jenkins is building the various micro services and pushing a new Docker Container to Amazon ECR and updating ECS.

Does this approach fit for each website?

Definitely not. For smaller websites this is overkill, but you still might want to take a look at e.g. Contentful and it’s middleman connector.

Is this a common trend?

As far as we see almost any huge Publisher is looking closer at that option. Google trend tells us there is growing interest as well:



So who is doing that all?

The great team below 🙂 IT Team


Image is licensed under CC BY 2.0