What are Drupal Recipes and how do you create one?

Every new Drupal build starts with the same checklist. Install Admin Toolbar. Add Header and Footer Scripts. Enable Views UI and Redirect. Then create the content types, the vocabularies, and the paragraph types you built on the last project.

On a single site, that's an afternoon. On a project with five sites that share a theme and most of their configuration, it's the same afternoon five times over.

This is the problem Drupal recipes were built for. Here's what they are, how they compare to installation profiles, where they fall short, and how to write your own.

Key Takeaways

• A Drupal recipe is a reusable package of modules and configuration that you apply to a site with a single command.
• Recipes need Drupal 10.3 or later. You can apply them at any point in a site's life, and you can apply as many as you need.
• Installation profiles are chosen once at install and can't be combined. Recipes are small, stackable and leave no dependency behind.
• A recipe is a folder with a recipe.yml file and an optional config/ folder. Apply it with drush recipe (Drush 13) or php core/scripts/drupal recipe.
• Because a recipe isn't tracked after it runs, later changes to it won't reach sites that already applied it.

What are Drupal recipes?

A Drupal recipe is a reusable package of modules and configuration that you apply to a site with a single command. You describe the end state you want in YAML, and Drupal's recipe runner gets the site there. That can mean installing modules, creating content types and vocabularies, setting up paragraph types or adjusting permissions.

Recipes arrived in Drupal core with version 10.3, released in June 2024. They shipped as an experimental API in that release, so expect some details to keep changing between minor versions.

They're now central to how Drupal itself ships. Drupal CMS is assembled from a curated set of recipes. Drupal CMS 2.0 was released in January 2026. The full specification lives in the Drupal recipes documentation.

How are Drupal recipes different from installation profiles?

If you've worked with installation profiles, this will sound familiar. Pick a profile at install, and Drupal builds the site from its configuration. The differences show up once the site exists.

How installation profiles work

A profile is code that lives in your webroot. It has an .info.yml file listing every dependency, plus .profile and .install files and a config/install folder holding the configuration.

You select a profile once, during installation, and you can't switch it later. You also can't combine two profiles. So one profile has to carry every piece of configuration the site needs.

How recipes work

Recipes can be as small as you want. One recipe can create a single content type. Another can set up your SEO modules.

You can apply several recipes to the same site, at any point in its life. Once a recipe runs, the site keeps no dependency on it. The configuration belongs to the site, and you can change anything afterward.

How do you create a Drupal recipe?

A recipe needs only a folder and a recipe.yml file. The example below installs a few admin modules and creates an Article content type and a Tags vocabulary.

Step 1: Make sure the modules are in your codebase

A recipe installs modules. It doesn't download them. Core modules like Node, Taxonomy, and Views UI are already there, but contrib modules need to be pulled in with Composer first, or the recipe stops with a "module not found" error.

composer require drupal/admin_toolbar drupal/redirect

Step 2: Create the recipe folder and recipe.yml

Make a folder named after your recipe, usually inside a recipes/ folder at your project root. Add a recipe.yml file that names the recipe and lists the modules to install.

name: 'Blog setup'
description: 'Installs admin modules and creates the Article content type and Tags vocabulary.'
type: 'Content type'
install:
  - admin_toolbar
  - redirect
  - views_ui
  - node
  - taxonomy

Step 3: Add your configuration files

Create a config/ folder inside the recipe and copy in the YAML for the configuration you want. Everything in a recipe's config/ folder is always imported when the recipe runs (Drupal recipes documentation). If you export these files from an existing site, delete the uuid and _core lines first so they don't clash with the target site.

recipes/
└── blog_setup/
    ├── recipe.yml
    └── config/
        ├── node.type.article.yml
        └── taxonomy.vocabulary.tags.yml

Step 4: Apply the recipe

Run one of these from your project root. Drush 13 provides the recipe command, and core's own script works without Drush. Clear the cache afterward.

# With Drush 13
drush recipe recipes/blog_setup

# Without Drush
php core/scripts/drupal recipe recipes/blog_setup

drush cr

When do you need the recipe unpack plugin?

You don't need it for a recipe that lives in a local folder, like the one above. The plugin matters when you install a recipe from Drupal.org with Composer. It moves the recipe's dependencies into your project's own composer.json, so you can delete the recipe later without losing the modules it needs.

The drupal/core-recipe-unpack plugin was shipped with Drupal 11.2, but it works on any Drupal version. If your project's composer.json doesn't already allow it, run these commands. The last one tells Composer to place recipe packages in a recipes/ folder.

composer config allow-plugins.drupal/core-recipe-unpack true
composer require drupal/core-recipe-unpack
composer require composer/installers:^2.3
composer config --merge --json extra.installer-paths '{"recipes/{$name}":["type:drupal-recipe"]}'

Can you build recipes on top of other recipes?

Yes. A recipe can list other recipes under a recipes: key, and those run first. If any of them fails, the parent recipe isn't applied either.

That makes layering easy. Keep a base recipe for the modules every site gets, then add one recipe per content model. Each new site becomes a short list of recipes, plus the changes that make it different.

name: 'Site starter'
type: 'Site'
recipes:
  - blog_setup
  - seo_essentials

Where can you find ready-made Drupal recipes?

You don't have to write every recipe yourself. Drupal.org lists contributed recipes on its recipes browse page, and you can require them with Composer like any other project.

Drupal CMS is the largest working example. Its recipes cover common needs such as clean URLs, redirects and breadcrumbs (drupal_cms_seo_basic), meta tags and XML sitemaps (drupal_cms_seo_tools), and spam protection (drupal_cms_anti_spam). Reading them is one of the best ways to learn how production recipes are put together.

Site builders can also apply recipes from the admin UI through Project Browser, so not every recipe needs a terminal.

What are the limitations of Drupal recipes?

The same design that makes recipes flexible creates a few trade-offs. Know them before you build a recipe library.

• No update path. A recipe is applied once and then forgotten. If you improve the recipe later, sites that already applied it won't get the change.
• No built-in rollback. There's no command to undo a recipe. Take a database backup first, or test on a copy of the site.
• Config conflicts. If the site already has configuration that differs from what the recipe ships, the recipe runner can stop with an error. Recipes are safest on sites you control end to end.
• An evolving API. Recipes started as experimental in 10.3. Check the documentation when you move to a new Drupal minor version.

When should you use Drupal recipes?

Recipes earn their place wherever the same setup repeats. These are the scenarios where they help most:

• Multisite builds. Several sites share a theme and content model but differ in content. One base recipe sets up each site in minutes.
• Agency starter kits. Package the modules and editorial defaults you use on every project, then layer project-specific recipes on top.
• Adding a feature to a live site. Apply an SEO stack, a blog or a spam-protection setup to an existing site without rebuilding it.
• Standardizing editorial config. Keep text formats, roles and permissions consistent across a portfolio of sites.

An installation profile still makes sense when you maintain a full distribution that controls the entire site from day one. For everything else, recipes give you finer control. Teams that offer Drupal development services across many sites will feel the difference first.

Final thoughts

Drupal has always rewarded teams that set up a site once and reuse what works. Installation profiles were the first big step, and they saved real development time. Recipes take the same idea further, because each piece of your setup becomes something you can apply on its own.

That changes how a multisite project starts. You keep a small library of recipes, apply the ones each site needs, and spend your time on what makes that site different.

The setup is light: a folder, a recipe.yml file, and one command. Turn the configuration you rebuild most often into your first recipe, and the afternoon you'd have spent on setup goes to real work.

Building several Drupal sites on a shared foundation? Specbee's Drupal team can help you plan a recipe library that fits your platform. Talk to our Drupal experts.

Frequently Asked Questions

Which Drupal version do I need to use recipes?

You need Drupal 10.3 or later to apply recipes. They arrived in that release as an experimental API in June 2024. Drupal 11 sites can use them too, and Drupal CMS is built from them. Local recipe folders work without extra setup. Installing recipes from Drupal.org with Composer works best with the core recipe unpack plugin.

Can I apply a Drupal recipe to an existing site?

Yes, recipes work on existing sites as well as new ones. That's one of their main advantages over installation profiles, which only run at install. A recipe installs its modules and imports its configuration into the live site. Test on a local or staging copy first, since a recipe can conflict with configuration that already exists.

Can I use more than one recipe on the same Drupal site?

Yes, you can apply as many recipes as you need. Recipes can also require other recipes, which run first. A common pattern is a base recipe for shared modules, then separate recipes for each content type or feature.

What happens to a recipe after it's applied?

Nothing stays installed. A recipe runs once and leaves no ongoing dependency on the site. The modules it installed and the configuration it created become ordinary parts of the site. You can edit or remove any of it later, just as if you'd set it up by hand.

Can I undo a Drupal recipe?

There's no built-in rollback for recipes today. Once a recipe runs, its modules and configuration are part of the site. To reverse it, you uninstall the modules and delete the configuration by hand, or restore a backup. Taking a database backup before applying a recipe to a live site is the simplest safeguard.

How are Drupal recipes different from configuration sync?

Configuration sync moves the full configuration of one site between its own environments, such as local, staging and production. Recipes apply a partial, reusable set of configuration to any site, including a brand-new one. Use config sync to deploy changes to a site you already have. Use recipes to set up the same features across different sites.

Do I need Drush to apply a Drupal recipe?

No. Drush 13 gives you the drush recipe command, which is the quickest option. Without Drush, run php core/scripts/drupal recipe path/to/recipe from the project root. Both commands apply the recipe the same way. Site builders can also apply some recipes from the admin UI through Project Browser.

Should I replace my installation profile with recipes?

For new builds, recipes are usually the more flexible choice. Drupal CMS, the official Drupal starter, is itself assembled from recipes. Existing sites built on a profile keep working. You can start adding recipes to those sites for new features without changing the profile.