CMS for Symfony: A PHP-Native Content Layer for Your App

Symfony is a serious PHP framework for building applications — robust, component-based, enterprise-friendly. What it isn't is a CMS. Symfony developers who need content management face the usual choices: build it with Sonata Admin and Doctrine, adopt a Symfony-based CMS like Sulu, or connect a headless CMS over an API. This post covers the headless route — how to wire a CMS to Symfony, what to fetch in a controller, and why a self-hosted content layer fits a PHP application stack.

Content options for a Symfony app

Build your own with Sonata Admin + Doctrine entities: full control, all in your Symfony app, but you build and maintain every content feature — media, SEO, scheduling, publishing workflow.

Symfony-native CMS (Sulu, or the older EasyAdmin-based approaches): a CMS built on Symfony that lives in or alongside your app. Deeply integrated, but a big adoption and a strong opinion on structure.

Headless CMS: content in a dedicated service with its own admin and API. Symfony fetches it. Loosest coupling, least to maintain in your codebase, and non-developers get a purpose-built editor.

If content is a blog and marketing pages rather than app-woven data, headless keeps your Symfony project focused.

Fetching CMS content in a Symfony controller

Symfony ships an HTTP client. Use it in a controller:

// src/Controller/BlogController.php
use Symfony\Contracts\HttpClient\HttpClientInterface;

class BlogController extends AbstractController
{
    public function __construct(private HttpClientInterface $client) {}

    #[Route('/blog', name: 'blog_index')]
    public function index(): Response
    {
        $response = $this->client->request('GET',
            'https://cms.yoursite.com/api/v1/posts?per_page=20');
        $posts = $response->toArray()['data'];

        return $this->render('blog/index.html.twig', ['posts' => $posts]);
    }
}

Cache responses (Symfony Cache component) so you're not hitting the API every request. The CMS returns a { success, message, data } envelope, and drafts return 404 — unpublished content never leaks.

Why a PHP-native CMS is a natural fit

Here's the nice part for Symfony: UnfoldCMS is built on Laravel — also PHP 8.3. You can run it two ways, and both share your operational world.

Headless — Symfony consumes the CMS's REST API at /api/v1/*. Clean separation, your Twig templates render the content.

Alongside — run UnfoldCMS as the content site (its own themes) on a subdomain or path, and keep your Symfony app for the application. Two PHP apps that deploy with composer, run on the same kind of hosting, and share your PHP ops knowledge.

Either way, the value is a shared stack:

• Same hosting — runs on the LAMP/PHP infrastructure your Symfony app already uses. No new runtime.
• Same deploy tooling — composer, PHP-FPM. Familiar.
• Same debugging — PHP stack traces you can read.
• Self-hosted, pay once — your server, your data, no subscription.

It's a self-hosted CMS with a React + shadcn/ui admin, so the editing experience is modern even though the runtime is familiar PHP.

Cache busting with webhooks

Cache CMS responses and clear them on content change. UnfoldCMS fires outgoing, HMAC-signed webhooks on publish/update/delete. Point one at a Symfony route that verifies the signature and clears the cache — an editor publishes, the stale cache clears immediately, no TTL wait.

Symfony content options compared

Sulu is the right answer when you want a Symfony-native CMS deeply integrated. A headless CMS is the right answer when content is a separable concern and you'd rather not adopt a whole CMS framework into your app.

Tradeoffs to weigh

• It's Laravel, not Symfony. Same language, different framework. You don't write in it, but if you wanted a Symfony-native CMS specifically, that's Sulu, not this.
• A separate app. UnfoldCMS isn't a Symfony bundle you install — it's its own Laravel application you run alongside.
• No revision history. UnfoldCMS doesn't keep past versions of posts.
• REST only, no GraphQL.

FAQ

Does Symfony have a built-in CMS? No. Symfony is an application framework, not a CMS. You build content management (Sonata Admin), adopt a Symfony CMS (Sulu), or connect a headless CMS via its API.

Can I use a Laravel-based CMS with a Symfony app? Yes. Both are PHP, so they share hosting and ops. In a headless setup, Symfony calls the CMS's REST API with the HTTP Client and renders the JSON in Twig — the framework difference is invisible to your app.

Is UnfoldCMS a Symfony bundle? No. It's a standalone Laravel application, not a bundle you install into Symfony. You run it alongside your app and consume its API, or use it as the content site directly.

Sulu or headless for Symfony? Sulu if you want a Symfony-native CMS tightly integrated. Headless (UnfoldCMS) if content is separable and you'd rather not pull a full CMS framework into your codebase.

Bottom line

Symfony builds applications, not content — so for a blog or marketing pages, you build it, adopt Sulu, or go headless. A PHP-native headless CMS like UnfoldCMS shares your hosting, deploy tooling, and ops knowledge (it's Laravel, same language), while keeping content a clean, separable concern. Run it headless behind Twig or as a standalone content site — either way, one PHP world, not two.

See the demo or read about CMS for PHP developers.

Related: CMS for PHP developers · CMS for Laravel · PHP headless CMS