Recipes, Site Templates, and Distributions: Modernizing the Approach to Repeatable Success with Drupal

Way back in the Portland 2022 Driesnote, Drupal creator and Acquia co-founder Dries Buytaert first proposed what were then called "Starter Templates". The vision was to make Drupal easier and faster to use, by having drop-in capabilities to address common site building needs: a staff directory, an events calendar, and so on. Drupal already had a concept of distributions and installation profiles that allowed for the creation of opinionated websites, but they had some issues.

For starters, they often became a maintenance challenge. A site based on a distribution is restricted to specific versions of Drupal core and any modules used, which means that if the distribution isn't well maintained, you can end up with sites that aren't up-to-date with security patches, or able to use the latest features. Also, distributions can only be used at the start of a website build, and it can be challenging to remove a distribution from a site once created. Finally, distributions aren't composable. You can't combine some features of the RedHen Raiser distribution, for example, with some features of the Commerce Kickstart distribution.

"Starter Templates" would eventually be renamed "Recipes", and have become the foundation for newer initiatives like Drupal CMS and Site Templates. At its core, a Drupal recipe is configuration instead of code. A recipe can pull in modules and/or themes and configure them, but a recipe can't contain any code of its own. One of the primary innovations of Drupal core's Recipes API is the concept of config actions. Config actions allow a recipe to be much more flexible in the ways it will alter a site's configuration. Critically, careful use of config actions allow recipes to be "idempotent": You should be able to apply the same recipe to the same site again and again, without errors. Recipes can also include content, so that after applying a recipe the feature it added is populated and ready to use.

When I first heard about Recipes, I wanted to help. I had already been working on what I had been calling “Configuration Kits” which were conceptually similar, in that they were meant to provide sets of configuration to solve common site needs. They were built as standard Drupal modules, however, so nowhere near as flexible. With some help from the team at Kanopi Studios, the existing Smart Date Starter Kit was converted to a recipe and became the basis for the Events recipe that was built for Drupal CMS.

More recently, in the Atlanta 2025 Driesnote, Dries proposed Site Templates and a marketplace for them, as a way to quickly spin up opinionated versions of Drupal that could meet the needs of industry-specific sites, without the lock-in that made distributions so challenging to work with. Conceptually, a site template is made up of one or more recipes, a theme, and demo content as a starting point.

Demystifying the Concept: What Is a Drupal Site Template?

Instead of a daunting "blank slate", a site template hands you an optimized package featuring pre-installed modules, tailored content models (complete with views, pre-configured taxonomies, and user roles), sample content to guide your layouts, and a fully responsive design system right out of the box.

A site template doesn't just save you from repeating the same mundane set-up tasks for every single project. It packages expert community knowledge and best practices into a cohesive, turnkey solution. It ensures that if you are building a site for a technology startup, a local municipality, or a higher education platform, you are starting with best-in-class configuration and architectural choices from day one, along with a purpose-built theme. It lets marketing teams and developers completely skip past "Phase Zero" and focus immediately on the custom branding and content that make their project unique.

The Architecture of an Ephemeral Solution

This is precisely where the Recipe API has become a game-changer. Unlike a distribution, a recipe is entirely ephemeral. It executes a specific set of configuration changes, installs modules, establishes content models, and can import default content; but once its job is finished, the recipe itself steps back. It doesn't become a permanent dependency. What you are left with is a standard, vanilla Drupal installation with all the beautiful, tailored configurations you need.

Let's look at a quick example of how clean this is. A typical recipe.yml file is totally declarative: it explicitly lists the modules it intends to enable, and the configuration it needs to enforce. It looks something like this:

name: 'Events Recipe'
description: 'A content type and view to help you manage events.'
type: 'Events'
install:
  # Core
  - menu_ui
  - node
  - user
  # Contrib
  - add_content_by_bundle
  - smart_date
  - date_augmenter
  - addtocal_augment
  - pathauto
config:
  import:
    # Contrib
    pathauto: "*"
    smart_date: "*"
  strict:
    - field.storage.node.body
    - field.storage.node.field_when
  actions:
    user.role.content_editor:
      grantPermissions:
        - 'create event content'
        - 'edit own event content'

When this recipe is applied via the command line or through the Drupal UI, the system reads these directives sequentially. It ensures the standard navigation recipe is applied first, enables the required modules, imports the specified configuration from those modules, imports any configuration included in the recipe, and executes the config actions. If the recipe includes content, it will be created as the last step. Afterwards, if  you decide that your site's events don't need a specific taxonomy, or if you want to swap out the Smart Date module for something else, you can do so through the standard administrative interface or your configuration synchronization workflow. The freedom to evolve is baked directly into the architecture.

How are recipes and site templates related? Remember that one of the goals of the Drupal recipe system is to be composable. Site Templates are the opposite: they’re meant to provide a fully-realized solution for a specific kind of website. That said, site templates and recipes have a lot in common. Neither will contain any code. Neither locks you in to a specific approach, or limits your ability to customize them once they’re applied to your site. Each is a starting point. In fact, not only can you apply recipes to a site created with a site template, a site template can include a curated list of recommended add-ons that will be shown in the Project Browser UI, making it easy for site builders to extend their site in useful ways. You could even say that site templates are a special kind of recipe.

Building on Drupal CMS

As a community, we got our first look at Site Templates in Drupal CMS 2.0, released in January 2026. Using the updated installer, you could choose between Byte or Starter templates. Both are based on the Mercury design system created by Current (previously known as Mediacurrent) and the Drupal CMS team. With the release of Drupal CMS 2.1 in March 2026, the number of site templates available at install grew to 11. Notably, the list also includes the Meridian Charter template, which requires purchasing a license from the team at Dripyard. In return, however, you get a fully accessible and professionally supported starting point for your Drupal site. You can also browse available site templates in a dedicated marketplace on drupal.org.

It’s worth noting that for a site template to be considered for inclusion in the Drupal CMS installer or the official marketplace, it needs to be based on Drupal CMS. When I first heard that, I’ll admit I was a little concerned. The first version of Drupal CMS was very opinionated in ways that were intended to make it easy for content editors on a simple publishing site out-of-the-box, but might not align with how you might want to build a Drupal site for other kinds of applications. The good news is that with Drupal CMS 2.0, a lot of that opinionated setup has been removed from the base, and is now meant to be provided by site templates instead. That means site templates can take advantage of the significant work and numerous best practices in the recipes that comprise Drupal CMS, but have significant flexibility to craft user experiences that align with complex use cases.

Roll Your Own

Hopefully by now you’re (nearly) as excited as I am about the potential for site templates. The good news is that you can create your own! Use the Drupal CMS Site Template Starter Kit to spin up a new Drupal CMS site (or just spin up a fresh Drupal CMS site using the Blank site template), add whatever configuration or additional dependencies (contrib modules or themes) you need for your solution to be complete, and then a quick drush site:export on the command line will generate the files for your site template. There are some additional steps to get it ready to share, so consult the included GET-STARTED.md for the full breakdown.

Naturally, the approach above is recommended if your site template will be based on Drupal CMS. That’s a requirement for a site template you’d like to be available in the official marketplace or (obviously) the Drupal CMS installer, but if you want to build a site template for a more specialized use case, you can turn any site built on Drupal core 11.2.4 or newer into a site template using similar steps by adding the Drupal CMS Helper to your site. Your site doesn’t need to be based on Drupal CMS to use the module, but the module is included automatically in Drupal CMS, so don’t get confused by the name.

If you’d like your site template to be included as free in the marketplace, the next step is to publish the site template (as a general project) and the theme (as a theme project – assuming you have created a new theme) on drupal.org. 

From there, you can apply to be a partner of the marketplace, which is open to organizations and individuals. There are a number of requirements on the next page, so make sure you’re comfortable with all of it. If approved, you’ll now be able to add your site template to the marketplace. It’s also worth taking note that the application suggests getting feedback on your site template’s intended use case and target vertical before investing time and effort on the actual development.

The Road Ahead and the Trusted Template Marketplace

So, where do we go from here? The launch of Drupal CMS 2.1 has given us a solid foundation, but the true potential of this architectural shift is only beginning to unfold. During the recent debut of the Trusted Site Template Marketplace at DrupalCon Chicago in March 2026, the energy in the room was palpable. For the first time, community members, agencies, and enterprise vendors have a centralized, secure venue to share both free and premium site templates. This marketplace isn't just a basic directory; it enforces strict validation standards to ensure that any listed template adheres to core security guidelines and cleanly utilizes the Recipe API without introducing hidden locks or bad architectural patterns.

As we look to the future, there are a few key priorities that could dominate our conversations over the coming months:

• Standardizing Multi-Site Governance: I suspect we will see large enterprise organizations adopting custom site templates as their preferred mechanism for maintaining corporate standards. A central IT team can maintain a "master template" recipe that enforces security policies, single sign-on integrations, and core branding, while still allowing individual departments or regional offices the autonomy to add their own local features without breaking the upstream configuration flow.
• Deepening AI Integration: There is a lot of truth to the idea that site setup is only half the battle. The next logical step is integrating AI utilities directly into the recipe application process. Imagine choosing a non-profit site template and having an integrated AI assistant automatically generate initial content drafts, structure local tax taxonomy terms based on your geographic region, and suggest optimal layout improvements based on real-time accessibility scans. As a site builder you can already use Drupal’s AI chatbot to help refine the content architecture after you’ve created a site from a template. Allowing for AI interaction during the site creation process could allow for a “shift left” of intelligent assistance.
• Expanding the Options: While the initial marketplace launched with 11 high-impact sector templates—including great options like the Byte template for technology startups and the Local template for public sector sites—we need more diversity. We need specialized templates for independent creators, research labs, regional sports leagues, and local community groups. The marketplace is currently accepting a second wave of templates.

Is this new direction going to solve every challenge we face when building for the open web? Certainly not. Building complex, enterprise-grade digital experiences will always require careful thought, sound data modeling, and a clear understanding of user needs. But by moving away from the rigid, restrictive world of traditional distributions and embracing the fluid, ephemeral nature of the Recipe API, we have finally removed one of the biggest roadblocks to long-term site sustainability.

I would love to hear from you. Have you had a chance to experiment with the Recipe API or explore any of the site templates available in the Drupal CMS 2.1 catalog yet? Are you planning to convert your agency's internal starter kits into public recipes? Please open an issue on the project queue, drop a comment on the community forums, or find me in the Drupal Slack channel to share your feedback. I hope other sites and their users will find this new way of building just as liberating and helpful as I do. Let's build something great together, without the baggage of the past.

Special thanks to Adam G-H (phenaproxima) and Pamela Barone (pameeela) for their review of this blog post, and to Tim Hestenes Lehnen (hestenet) for providing input.