prelo
Definitions

What is a decoupled CMS?

A decoupled CMS separates where content is managed from where it is rendered: editors work in an admin, the frontend is its own application, and an API connects the two.

In a traditional CMS (classic WordPress, Squarespace), the CMS renders the pages itself — content and presentation live in one system. In a decoupled architecture, the CMS keeps an editing interface and a delivery API, but your own frontend consumes that API and owns the rendering. Headless goes one step further: the CMS ships no frontend opinion at all — it is only an API and an admin.

Traditional
Decoupled
Headless
Who renders pages
The CMS
Your frontend (CMS can fall back)
Your frontend, always
Editing UI
Built in
Built in
Built in or bring-your-own
Frontend stack
The CMS’s templates
Anything
Anything
Typical example
Classic WordPress
Drupal + JS frontend
Sanity, Strapi, Prelo

When decoupling is worth it

You want a modern frontend stack (Next.js, Astro, SvelteKit) with real performance control.
The same content feeds several surfaces — site, app, agents.
Developers and editors need to work without stepping on each other.

And when it isn’t: a small site whose editors just need pages to exist. Decoupling adds an API hop and a second deployable — only pay that cost for a reason. More definitions: what is a git-based CMS?

Where Prelo sits

Prelo is headless with the sharp edges filed off: the studio, content API and database ship in one container next to your frontend, so “decoupled” stops meaning “six vendors.” See how it works.

Ready to hand over your next site?

Free and open source. One command, and the client gets a login instead of a Loom.

Start a project — free