Magnolia Frontend Options: Headless Storefront for Magnolia CMS

If you run Magnolia CMS, you have more than one frontend option today: classic FreeMarker templating at the core, Magnolia's own headless mode with the React SDK and Headless Accelerator, or a standalone Composable Frontend that treats Magnolia purely as a content backend. Which option fits depends on how much marketing autonomy and how much frontend control your team actually needs.

What Are the Frontend Options for Magnolia CMS?

Magnolia's classic path renders content server-side, straight out of the authoring tree via FreeMarker templates. Editors see the page in the WYSIWYG editor, developers maintain the templates. That works well for classic websites, but it ties frontend delivery tightly to Magnolia's own render cycle.

For several versions now, Magnolia has also shipped a headless mode: content delivery over REST and GraphQL delivery APIs, plus a React SDK and the Headless Accelerator, which spins up a React or Next.js project from the CLI. Teams in a commerce context get pre-built integrations for Vue Storefront, SAP Spartacus, and Salesforce Composable Storefront. Magnolia also supports a hybrid setup: one site rendered classically through FreeMarker, another headless through React, both running on the same instance.

That leaves you with three core paths: classic template rendering directly in Magnolia, a custom-built frontend on top of Magnolia's React SDK and Headless Accelerator, or a separately operated Composable Frontend that connects through the delivery API and is deployed, scaled, and developed fully independently. We break down the second and third path, including when the switch actually pays off, on our Magnolia page builder page.

The Problem: FreeMarker Templating vs. Frontend Speed

The classic path is fastest to set up when your team already knows FreeMarker. But every new landing page, every campaign variant, and every Core Web Vitals fix then runs through the same render cycle as the rest of the site, usually behind a developer ticket. Marketing waits on engineering, engineering waits on the next release slot.

Magnolia's Headless Accelerator solves part of that: you get a modern React or Next.js setup, decoupled from FreeMarker. What the Accelerator doesn't ship is the operations that come after. Component library upkeep, Core Web Vitals monitoring, multi-locale sync, and a visual editor for marketing are all tasks your team has to build and keep running yourself. What that operating load actually looks like is well documented in the real cost that shows up after a headless CMS go-live: going headless is rarely the finish line, it's the start of a new operating model.

For an enterprise team with real frontend ambitions, the build-it-yourself route is doable. But it's a second product living next to Magnolia itself, with its own maintenance load, its own CI/CD, and its own security patch cadence.

What a Composable Frontend for Magnolia Looks Like

This is exactly where a Frontend Management Platform (FMP) like Laioutr comes in. Magnolia stays your full content backend, authoring, workflow, permissions, and digital asset management keep running exactly as they are. Laioutr pulls content through Magnolia's REST and GraphQL delivery API and renders the storefront as an independent Composable Headless Frontend, on a Next.js or Nuxt runtime, with edge caching and its own deployment cycle.

The difference from a custom build: the component library, the Visual Page Builder, Core Web Vitals tuning, and multi-locale rendering are part of the platform, not part of your backlog. Your content team keeps editing pages in Magnolia or directly in the visual frontend editor, and your dev team builds components instead of maintaining a CI/CD pipeline for a homegrown Accelerator setup. From the developer's perspective, that means clear APIs instead of custom glue code between the React SDK and the delivery API, TypeScript components instead of template debugging.

If Magnolia is ever supplemented or replaced by another backend down the road, your frontend keeps running, because it was never coupled to FreeMarker or Magnolia's rendering layer in the first place. Other CMS teams solve the same question differently, but with the same underlying pattern, for example in the TYPO3 frontend without the Fluid templating build: the backend stays, the frontend decision gets made independently.

Which Option Fits Which Team

• Classic FreeMarker rendering: fits when your team is small, the site doesn't need much campaign velocity, and editorial and engineering work closely together.
• Custom build with the React SDK and Headless Accelerator: fits when your dev team is large enough to run a component library, monitoring, and editor tooling on its own, indefinitely.
• Composable Frontend as a managed layer: fits when multiple brands or markets run on one Magnolia instance, Core Web Vitals pressure is high, and editorial and frontend engineering need to work decoupled, without your team operating two separate tech stacks.

What You Get

• Dimension | FreeMarker (Classic) | Custom Build (React SDK) | With Laioutr
• New landing page | Developer ticket, days to weeks | Developer ticket, days | Editor, hours
• Core Web Vitals | depends on the template | requires your own monitoring | edge caching out of the box
• Operating load | low, but rigid | high, a second product | owned by the platform
• Backend coupling | tightly tied to Magnolia rendering | loose, but custom glue code | decoupled, reversible

FAQ

Can I run Magnolia headless without changing my authoring process? Yes. Magnolia stays your content backend, including authoring, workflow, and permissions. Only delivery changes, from server-side FreeMarker rendering to a delivery API that feeds a separate frontend.

Do I need Magnolia's Headless Accelerator if I use Laioutr? No. The Headless Accelerator is Magnolia's own path to a custom-built frontend. Laioutr replaces exactly that custom build with an operated platform that connects directly through the REST and GraphQL delivery API.

Does this work when multiple brands or markets run on one Magnolia instance? Yes, that's one of the cases where a Composable Frontend pays off the most: multi-brand and multi-market rendering happen centrally in the frontend, while Magnolia stays a single content source of truth.

What does this cost? Pricing depends on scope and operating model, and it's calculable at laioutr.com/en/pricing. The real comparison isn't against doing nothing, it's against the ongoing cost of running a self-built Headless Accelerator setup.

How long does implementation take? Because Magnolia stays unchanged and only the frontend gets decoupled, we're talking weeks, not a year. Typical range: 6 to 8 weeks to your first live storefront, depending on the number of templates and locales.

Next Steps

Whether you're still on classic FreeMarker rendering or already running a Headless Accelerator custom build: book a frontend check for your Magnolia instance, and we'll walk through together which of the three options actually brings your team the lowest operating load for the most marketing autonomy.

About the Author: The Laioutr Team works daily with enterprise dev-teams to connect content backends like Magnolia to an independently operated Composable Frontend, without replatforming risk.