Drupal CMS is a pre-configured distribution of Drupal, not a different product — the same core, the same entity system, the same modules, shipped with the decisions already made for you.
That sentence answers most of what people are actually asking, and it is worth being blunt about it because a lot of coverage implies a fork or a rewrite. There is no second codebase. If you know Drupal, you know Drupal CMS; what changes is where you start from.
Distribution, not platform
A Drupal distribution is core plus a chosen set of modules, themes and configuration, packaged so that installing it gives you a working site rather than an empty one. Distributions have existed for years — Commerce Kickstart, Varbase, OpenSocial. Drupal CMS is the first one produced by the project itself as the recommended starting point for people who are not developers.
What it changes:
- The install asks what kind of site you want and configures accordingly, rather than handing you an empty site and a module list.
- The defaults are opinionated — editorial roles, text formats, an admin experience — instead of minimal.
- The framing is at content teams and marketers rather than at developers.
What it does not change: the entity system, the field API, Views, the render pipeline, the permission model, the theme layer, or how you deploy. Those are core, and they are identical.
Recipes are a core feature, not a Drupal CMS feature
Recipes get talked about as though Drupal CMS invented them. They did not — the recipe system lives in core. On Drupal 11.4.6 there are 28 recipes in core/recipes/ and the API sits in Drupal\Core\Recipe, with RecipeRunner doing the work.
A recipe is a YAML file that declares which modules to install and which configuration to import or alter. Reading core/recipes/article_content_type/recipe.yml, it installs image, node and path, then imports the view modes and actions that content type needs. Recipes can also compose other recipes — core/recipes/standard/recipe.yml pulls in eleven of them and layers its own permissions on top.
Two consequences worth knowing:
- You can use recipes on any Drupal 11 site. You do not need the distribution. If what appealed to you about Drupal CMS was one-command feature installation, that capability is already in your existing site.
- A recipe applies once and then it is just configuration. It is not a live dependency you keep. Applying one is closer to running an installer than to enabling a module, which matters when you are reasoning about what to put in version control.
If configuration and deployment are the parts you are unsure about, how Drupal configuration management works is the prerequisite reading, and it applies identically either way.
If you are deciding between the distribution and a plain install for a real project, Drupal services covers how that decision gets made.
Who it is genuinely for
| Situation | Better start | Why |
|---|---|---|
| Evaluating Drupal, no Drupal experience | Drupal CMS | You see a working site instead of an empty one |
| Small team, standard content site, no developer | Drupal CMS | The defaults are ones you would probably have chosen |
| Agency with an established build process | Core | You already have your own opinionated starting point |
| Unusual content model from day one | Core | You will spend time removing defaults you do not want |
| Migrating an existing complex site | Core | The migration defines the structure, not a starter config |
The pattern is straightforward: the distribution is worth most when its assumptions match yours, and costs a little when they do not. Unwinding defaults you did not want is real work.
The gap it does not close
Coverage of Drupal CMS routinely lists automatic updates among its benefits. That is not accurate, and it is the one claim worth being careful about because getting it wrong leaves a site unpatched.
In core 11.4.6, package_manager — the API that stages Composer operations in a sandbox before applying them — carries lifecycle: experimental and hidden: true in package_manager.info.yml. There is no automatic_updates directory in core at all. Core's Update Status module reports that a release exists; something else has to apply it, and that something is a contributed module, a managed host, or a person.
A distribution could close this gap, because automatic_updates is a separate Composer package that anything is free to require — and Drupal CMS does not require it. I checked its composer.json: the package is absent, so on this point Drupal CMS behaves exactly like plain Drupal. Plan for who owns patching before launch.
Common questions
Is Drupal CMS replacing Drupal?
No. Core continues exactly as it is. The distribution is a packaging of core, which means it can never diverge from it.
Can I move from Drupal CMS to plain Drupal later?
There is nothing to move. Once installed you have a Drupal site with a particular configuration. Change the configuration and you have a different Drupal site.
Will contributed modules work on it?
Yes. Anything compatible with the underlying core version works, because that is the only thing being checked.
Does it make Drupal easier to maintain?
Not materially. It makes it easier to start. Maintenance is Composer, updates and configuration deployment, and those are unchanged.
Was this the Starshot initiative?
Yes. Starshot was the working name during development; Drupal CMS is what shipped. Anything still describing them as two things is out of date.
What to do with this
If you are evaluating Drupal, install the distribution — it is the fastest way to see what the platform does without configuring anything first. If you are choosing between Drupal and something else entirely, the distribution is not the deciding factor and the platform comparison is the more useful page. If you are migrating an existing site, start from your content model rather than from anybody's defaults.
When the question stops being "what is this" and becomes "what should we build on it", that is where a Drupal architect earns their fee — and a short description of your project is usually enough for me to say whether the distribution helps you or gets in your way.
