Sulu

Last reviewed Sep 13, 2026 · 845 words

Sulu is a CMS for teams that already have a Symfony developer and would rather extend a framework they know than learn a CMS's own way of doing things. Everything about it follows from that: content types are XML template definitions in your repository, the admin is a React app that reads those definitions, deployment is composer install plus a Symfony cache warm-up, and nothing works until someone comfortable with bin/console has spent a day on it. The catalogue rates it Hard and lists 1 GB of RAM; both are right, and both are irrelevant to the target user, who runs Symfony already.

Two kernels, one repository

A Sulu install is a Symfony application with two entry points. The "website" kernel renders public pages through Twig templates; the "admin" kernel serves the editorial UI at /admin and the JSON API it talks to. They share the database, the content repository, and your bundle code, so a custom entity you add for the admin is immediately available to the front end. Commands are split the same way: bin/console for the website context and bin/adminconsole for admin tasks like building the search index or creating users.

Page types are declared in config/templates/pages/*.xml: a template name, a Twig file, and a list of typed properties (text line, rich text, media selection, block collection). The admin renders a form from that file with no further work. This is the mechanism that makes Sulu feel fast to developers and opaque to everyone else; a marketer cannot add a field, and that is the point.

Install, in the order that avoids the two common failures

composer create-project sulu/skeleton my-site
cd my-site
# set DATABASE_URL in .env.local, MySQL 8 or PostgreSQL both fine
bin/adminconsole sulu:build dev
symfony server:start

sulu:build dev creates the schema, the default webspace, and an admin user, then loads fixtures. The first failure people hit is running it before DATABASE_URL is correct; it fails half-way and leaves a partial schema, so drop the database and rerun rather than patching. The second is the webspace: config/webspaces/*.xml defines the site's locales, URL scheme, and default templates, and a locale added later needs the content repository re-indexed. Decide on your languages before you build.

Production needs PHP 8.2 or newer, a web server pointing at public/, APP_ENV=prod, and a cache warm-up on each deploy; the Docker route is the same as any Symfony app, one PHP-FPM container plus nginx plus the database. Search uses a bundled engine by default and can point at Elasticsearch for large sites.

What it is good at

Multi-site and multi-locale are first-class: one install serves 10 country sites with shared media, per-locale content trees, and fallbacks to a default language. Structured content with reusable blocks means the same components appear in a consistent order on 400 landing pages. There is a headless bundle that exposes pages and navigation as JSON for a Next.js or Nuxt front end. Media management handles image formats and focal-point cropping server-side. Roles and permissions are granular down to a webspace and a content type. Everything is unit-testable because it is PHP classes under Symfony's dependency injection.

Those are enterprise requirements, and the projects Sulu names as targets, Adobe Experience Manager and Sitecore, charge six figures for them. Around 1,350 stars is small for a CMS, but the user base is agencies, and agencies do not star repositories.

Who should choose something else

Bloggers and small businesses: WordPress or a flat-file engine will be live before Sulu finishes composer install. Teams without a PHP developer: nothing here works for you. Content teams who need to design their own fields in the UI: Drupal does that with a comparable enterprise feature set and a far larger community. Teams that want a headless API and a nice admin without a rendering layer: Strapi or Directus. Germanophone enterprise shops deciding between Sulu and TYPO3 usually end up on TYPO3 for the ecosystem and on Sulu when their developers refuse to leave Symfony conventions. The rest of the CMS category is for people who want the CMS to be the product; Sulu is for people who want it to be a library.

What I'd do

If I ran a Symfony shop building a multi-country marketing site with an editorial team of 5 to 50, Sulu is what I would quote, because the content model lives in the repository, the admin is generated from it, and every deploy is a pull request. I would put it on 2 GB rather than the 1 GB minimum, use PostgreSQL, add Elasticsearch once the page count passes a few thousand, and budget a week for the first webspace. If I did not have that developer, I would not touch it, and I would pick Drupal for the same requirements or WordPress for smaller ones.