Drupal Recipes for repeatable site configuration

Drupal Recipes apply module installs and configuration to sites that already exist, which lets teams standardize features across many sites. This page explains what they do, where they fit, and what to plan before building one.

Book a callTalk to us
On this page

When Drupal Recipes fit repeatable site configuration

Drupal Recipes automate module installation and configuration on an existing Drupal installation, according to the Drupal Recipes documentation. A Recipe can install modules and themes and apply configuration, so a feature that would otherwise be rebuilt by hand in each site becomes a repeatable set of steps. The typical situation is a team that enables the same stack on several sites, such as a media block, a standard contact form, consent settings and a set of Views, and wants each new site or existing site to receive the same result. The second common case is adding one bounded feature to a site that is already in production, where a Recipe gives the change a defined input and a record that can be reviewed in version control instead of a list of clicks in the admin interface.

Recipes fit best when the feature is stable, the configuration is largely the same on every target, and the differences between sites can be expressed as a few inputs. Before committing, confirm with your Drupal team which module versions the Recipe pins, whether it works on the Drupal major version you run today and the one you plan to move to, and which settings must stay site specific, such as domains, identity provider endpoints and retention periods. Recipes are the wrong tool when the site needs a custom data model, bespoke code or content that differs significantly from site to site. In those cases a custom module or a full install profile gives more control. A Recipe that tries to cover every site variation usually becomes harder to maintain than the manual work it replaced.

How Recipes differ from install profiles and distributions

An install profile runs when a Drupal site is first installed. It defines the modules, configuration and initial content that the site starts with, and it is selected during the installation process. Once the site exists, the profile has done its job, and it does not act as a continuing source of configuration for that site. Changes made later belong to the site itself, so a profile is best understood as a starting point rather than a live template.

  • When it runs: Only during site installation, before the site is in use.
  • What it owns: The initial set of modules, configuration and content created at install time.
  • How it is maintained: The profile is code in the project that defines it. Updating the profile does not change sites that were already installed from it.
  • Typical use: A new site that should start from a known baseline.
  • Limit to plan for: Teams that need the same features added to sites already running cannot rely on a profile for that.

Before choosing a profile for an existing estate, confirm with your Drupal team how the profile would be applied to sites that are already live and what would happen to configuration that has since been changed.

Which recipe approach fits each configuration job

This table compares the four ways a team can package configuration as a recipe, from a single-site feature to a custom in-house recipe applied across a multisite estate. Read each row against the configuration job in front of you, then check the trade-offs before choosing an approach. Recipe behavior changes between releases, so confirm current details in the Drupal Recipes documentation before you commit.

ApproachWhen it fitsWhat it changesTrade-offs
Single-site feature recipeOne site needs a bundle of modules and settings added to an existing installation, such as a standard contact form and its permissions.Installs the listed modules or themes and applies configuration to that one Drupal installation.Easy to review and rerun on one site, but the steps must be maintained by hand for any copy made later.
Shared recipe across a multisite estateMany sites under one codebase need the same feature set, such as consistent editorial roles or accessibility settings.Applies the same module and configuration steps to each site that runs the recipe, so the sites stay aligned.Saves repeated setup, but a change for one site can affect all sites that share it, so test each site before rollout.
Contributed recipe used as-isA recipe on Drupal.org already covers the job and its module choices fit your governance rules.Installs the modules and configuration the recipe author defined, identified by a composer.json type of drupal-recipe.Fastest route, but you inherit the author's choices and maintenance. Review the code and confirm it works with your Drupal version.
Custom in-house recipeYour organization has its own standard configuration that no public recipe matches and you want it versioned and repeatable.Defines your own installation and configuration steps, stored with your code and deployed through your release process.Fits your standards exactly, but your team owns the recipe through every Drupal upgrade and module change.
Recipe versus install profileYou are starting a new site and need a complete distribution, not an addition to an existing one.An install profile sets up the whole site at installation time, while a recipe is applied to an installation that already exists.Use a recipe to extend a live site. Confirm in the Drupal.org documentation whether a profile or distribution suits a fresh build.
Recipe applied to a Drupal 7 siteA Drupal 7 site is being moved to a current version.Recipes apply to current Drupal installations, not to Drupal 7 sites that must be migrated into a new site.Plan the migration first, then apply recipes on the new site. Drupal 7 themes must be rebuilt because they cannot be migrated.

How to build and apply a recipe on an existing site

This sequence turns a set of site-building decisions into a versioned recipe that can be tested on a copy of a live site, applied through a Composer-managed build, and checked against an expected configuration state. The result is a repeatable change that a second site or a later release can apply the same way.

  1. Define the feature inventory

    The site owner and the delivery lead list every module, theme and configuration item the feature needs, such as content types, fields, views, roles and text formats. Each item gets a named owner and a note on whether it is a contributed or custom module. The step is complete when the inventory is agreed in writing and every item can be traced to a business requirement. Ask the partner or internal team to flag any item that depends on another module so the install order is clear before any recipe file is written.

  2. Write the recipe and its configuration steps

    A developer creates the recipe directory with a composer.json that uses the drupal-recipe type, a recipe.yml file that lists the modules and the configuration to apply, and any default content or config files the feature needs. Each module is declared once, with its dependencies handled by the recipe rather than repeated by hand. The step closes when the recipe applies to a clean Drupal installation without errors and the resulting configuration is committed to version control.

  3. Test the recipe on a copy of a representative site

    The team takes a recent copy of a production-like site, including its contributed modules and content types, and applies the recipe to it in a non-production environment. Testers check for conflicts with existing fields, views, permissions and custom code, and record every error or manual fix needed. The step is done when the recipe applies cleanly twice in a row on fresh copies, which shows that it is repeatable and not dependent on leftover state.

  4. Apply the recipe through a Composer-managed build

    The recipe is added to the project's composer.json as a dependency, or placed in the repository the build pulls from, so the same version is installed in every environment. The deployment pipeline runs the recipe as part of the build or release step, with the commit or tag that produced it recorded. The step is complete when the lock file shows the recipe and its modules at pinned versions and the change is deployed to staging through the normal release path.

  5. Verify the configuration against the expected state

    After the recipe runs, the team exports the active configuration and compares it with the configuration stored in the repository, looking for any drift. They also list enabled modules and confirm that nothing outside the feature inventory was switched on, and they check roles and permissions against the agreed matrix. The step is done when the export matches the expected state with no unexpected differences, and the results are saved as evidence for the change record.

  6. Confirm the feature behaves as specified

    Business owners and testers walk through the user journeys defined in the inventory on staging, including editor and anonymous visitor paths. They confirm that the feature works with the production theme, search and caching layers, and any integrations already in place. The step closes with signed-off acceptance notes, and any defects are logged against the recipe rather than fixed by hand on the live site.

  7. Record the version and plan the next apply

    The team tags the recipe version, documents the inventory, the install steps and the verification results, and notes which sites it has been applied to. They also record how changes to the recipe will be tested before they reach other sites in the estate. The step is complete when the documentation lives beside the recipe in the repository and the owner of future changes is named.

Where recipe-based configuration goes wrong

Recipes make site configuration repeatable, but they only do so when the target sites start from a known state and the code they pull in is reviewed. The cards below cover the risks that show up most often on existing sites and multisite estates, and the control that addresses each one.

Recipes applied to diverging sites

A recipe assumes the configuration it touches looks the way its author expected. On a site where content types, fields, or views have been edited by hand, applying the recipe can overwrite settings, duplicate fields, or fail halfway. Before any rollout, export each site's configuration and compare it with the recipe's expected starting state. Group sites that match, and handle the outliers separately instead of applying one recipe to all of them.

Contributed recipes with uncertain upkeep

A contributed recipe is a general project, and its maintainers may not track every Drupal core or module release. Check the project's recent commits, open issues, and the versions of Drupal and modules it declares support for. If upkeep is unclear, copy the recipe into your own repository and maintain it as internal code, with an owner who fixes it when dependencies move.

Drift after manual changes

Once a recipe has run, administrators often adjust the same settings through the interface. The next run either reverts those changes or silently skips them, and nobody knows which happened. Decide which settings are owned by the recipe and which are owned by site builders, and record that split in the recipe's documentation. Compare exported configuration against the recipe after each release so drift is found by a check, not by a user report.

Module version conflicts during core upgrades

A recipe pins or assumes specific module versions. When Drupal core moves to a new major version, those assumptions can break, and a recipe that worked last year may fail on a site being upgraded. Test every recipe against the target core version in a staging copy of the site before the upgrade window opens. Treat recipe compatibility as part of the upgrade plan, alongside the modules themselves.

Unreviewed modules pulled in by recipes

A recipe can install modules and themes that nobody on the project chose directly. Each dependency adds code, permissions, and maintenance work. List every module a recipe will install, including transitive dependencies in composer.json, and review each one against your security and code review rules. On governed sites, pair this with a restricted Project Browser policy so site builders cannot add modules outside the reviewed set.

How recipes interact with core upgrades and version support

A recipe runs on top of a specific Drupal core version, so its value depends on that version staying supported. Drupal 11 is the current major version. Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Plan the recipe library against the version you will run for the next several years, not the version you installed last year. The PHP floor also changes with each major version: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. A recipe that pins contributed modules which do not yet support the next core release will block the upgrade, so record the module versions each recipe depends on in its composer.json.

Before every core upgrade, run each recipe against a copy of the site built on the target version. Apply the recipe to a clean target install and to a restored copy of production, then compare the resulting configuration with what is live. Look for dependencies that were removed or renamed, config keys a recipe writes that the new version no longer accepts, and steps that fail silently because a module changed its install hooks. Confirm the release notes for each contributed module the recipe installs, since a recipe cannot detect a changed default on its own. Treat a failed recipe run on the target version as a release blocker, the same as a failed automated test.

Drupal 6 and 7 sites are a different case. Drupal.org documentation states that these sites cannot simply be updated to Drupal 10 or later, and they must be migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, with themes rebuilt because they cannot be migrated. Recipes do not replace that migration, so do not design a recipe to convert a legacy site in place. Drupal 7 security support ended on January 5, 2025, so a site still on Drupal 7 that cannot migrate yet needs a separate decision about extended support, which the Drupal Association lists through its extended security support provider program. Confirm the current status of those vendors directly before you rely on them.

Questions buyers ask about Drupal Recipes

Can a Drupal recipe run on an existing site?

Yes. A recipe can install modules and themes and set up configuration on an existing Drupal installation, so it does not require a fresh site. The practical question is what the recipe changes. Before running one on production, check which modules it installs, which configuration it overwrites, and whether it creates content types, fields or views that already exist on your site. Run it first on a copy of the production database and codebase, review the configuration diff, and confirm the rollback plan. Read the Drupal Recipes documentation for the current behavior of the recipe system.

How does a recipe differ from an install profile or distribution?

A recipe is a set of steps that applies modules, themes and configuration to a site that already exists, so it can be reused on sites that were built differently. An install profile or distribution defines the whole site at installation time, including its starting structure and defaults. Use a recipe to add a capability such as a standard content model or a consent setup. Use a distribution when you want a complete, opinionated starting point for a new site. For a multisite estate, recipes are usually the better fit because they layer onto each site without replacing its installation.

What drives the cost and effort of building Drupal recipes?

The cost depends on how many features the recipe covers, how many contributed modules it depends on, and how much of the configuration is custom. A recipe that only installs a few well-documented contributed modules and imports their settings is far less work than one that encodes content types, workflows, permissions and integration settings for several sites. Other factors are how many sites must match the recipe, how many environments must be tested, and whether the team needs documentation and a review process. Ask any provider for a written scope that lists each module, configuration set, test environment and handover item before agreeing a fixed price.

What does the client team need to provide for a recipe project?

The client team needs to name the features that the recipe must standardize, confirm which contributed modules are approved for use, and identify the sites or environments where it will run. It also needs access to a staging copy of each target site, a code repository where recipes and custom code are stored, and a named owner who can approve configuration decisions. Without a clear owner for each decision, configuration drift between sites is likely to return. Plan time for stakeholders to review exported configuration, because most rework comes from settings that were assumed rather than agreed.

Can our internal staff maintain recipes after the project ends?

Yes, if your team has Drupal developers who understand Composer, configuration management and contributed module updates. Maintenance includes updating the recipe when a dependent module changes its configuration schema, testing the recipe against each new Drupal core release, and documenting which options a site builder may change. The recurring work is usually lower than the build, but it is not zero. Ask for a handover that covers the repository structure, the test steps, the rollback procedure and a list of dependencies with their maintenance status, so your staff can run the work without the original builders.

How do recipes fit into a multisite Drupal estate?

Recipes suit a multisite estate because one recipe can be applied to many sites, which keeps shared features consistent. The design work is to decide which settings are fixed across all sites and which are site-specific, such as branding, languages or integration credentials. Store secrets outside the recipe and keep site-specific values in each site's own configuration. Test the recipe on one representative site before rolling it out, and track which version each site has applied. Recipes reduce drift, but they do not replace a deployment process, so pair them with Composer-based releases and a record of applied recipes per site.

What should we confirm before committing to a recipe project?

Confirm the Drupal core version you run and whether it is supported, because recipes must work with the core release on each site. Confirm the PHP version, the database and the web server against the Drupal system requirements. Check the maintenance status and license of each contributed module the recipe depends on, since Drupal and contributed projects on Drupal.org are generally GPL-2.0-or-later. Ask the provider how it will test the recipe, who signs off on configuration, and what happens when a dependency changes. Put these answers in the written scope before work starts.

Security and operational considerations for shared recipes

A recipe is a short script that installs modules and writes configuration, so whatever it pulls in and whoever runs it becomes part of your production change set. The cards below cover the controls that keep recipe-driven changes reviewable, from the contributed code they install to the records left behind after each run.

Review third-party modules pulled by recipes

A recipe's composer.json and recipe file name every module and theme it installs, and those dependencies can bring in further contributed code. Before a recipe reaches a governed site, review each project's maintainer, release history, open issues and license, and pin exact versions in your Composer lock file. Ask whether any dependency is abandoned or only lightly maintained, because a recipe that installs it inherits that risk on every site it touches.

Keep secrets out of recipe files

Recipes are plain files that get committed, copied between sites and shared across a multisite estate, so API keys, SMTP passwords, SSO client secrets and database credentials must never appear in them. Set those values through environment variables, your secrets manager or the site's settings file outside the recipe, and have the recipe reference only the configuration keys. Scan recipe repositories for credential patterns before each merge.

Control who applies recipes to production

Applying a recipe on an existing site changes modules and configuration in one step, so the ability to run it should sit with a small group of release owners, not with every site builder who has Drush access. Restrict production application to your deployment pipeline or a change approval, and require that the same recipe version was tested on staging first. Document who holds that role and review the list when people change teams.

Record each recipe run as a change

A recipe that installs modules and writes configuration should leave a trace you can audit: the recipe version, the commit it came from, the operator, the target environment and the resulting configuration export. Keep these records alongside your normal change tickets and ensure the exported configuration is committed to version control after the run. Without this trail, a later configuration drift is hard to attribute to a specific recipe.

Track Drupal Security Team advisories for installed projects

The Drupal Security Team publishes advisories with CVE identifiers and risk scores for core and contributed projects, and it releases security fixes on the third Wednesday of the month. Because a recipe installs contributed projects, every site that applied it is exposed when one of those projects is affected, so subscribe to advisories for each project a recipe installs and record which sites run it. Plan the update through the same change process rather than applying the fix ad hoc.

What DeployOpen needs from your team to scope recipe work

Scoping recipe work starts with a complete list of the sites that will consume the recipes, including each site's owner, its Drupal version, its hosting location and whether it is a standalone install or part of a multisite. Recipes apply to an existing Drupal installation, so every site on the list needs a known starting point. Ask your team to confirm which sites are in scope now and which will join later, because a recipe that touches five sites is scoped differently from one that must reach fifty.

Next, provide a configuration baseline for each site. That means a configuration export from the active site, the list of installed modules and themes with their versions, and any settings that were changed by hand and never exported. Recipes can install modules and themes and set configuration, but they cannot tell you what drift already exists. Confirm with your team which sites are known to diverge, since those sites will need a reconciliation step before a shared recipe can be applied without surprises.

Third, document your module governance rules: which contributed projects are approved, who reviews new code, and whether site builders may install modules outside a reviewed list. This determines which modules a recipe may declare and how it is pinned in composer.json. Also state the target Drupal version for the recipe and the upgrade timeline for each site, because a recipe written for one major version must be tested against the version your sites will run next. Current release dates are listed on the Drupal core release schedule, and your team should confirm them before the scope is written. Engagements are fixed-scope, so the written scope will list deliverables and timelines before work begins, and the quote follows from that scope. DeployOpen does not publish a price list.

How DeployOpen scopes, builds and supports Drupal recipes

DeployOpen plans and builds Drupal Recipes as written, testable configuration that teams can apply to existing sites and across a multisite estate. Work is agreed as a fixed scope, with the recipe contents, target sites and handover documented before any build starts.

How we scope

  • Inventory the modules, themes and configuration each target site already runs, and note where they differ.
  • Define which features the recipe installs, which settings it sets and which content or config stays site-specific.
  • Agree the Drupal core version, PHP version and contributed module versions the recipe must support in writing.

How we build

  • Write the recipe in a Composer-managed project so module versions and dependencies are pinned and reviewable.
  • Test the recipe on a clean copy of each target site type, then on a copy of a real site with its existing configuration.
  • Check that re-running the recipe is safe and that it does not overwrite settings a site has changed on purpose.

How we hand over

  • Document each recipe's inputs, what it changes, known limits and the steps to apply it to a new or existing site.
  • Provide the recipe source, test results and a rollback approach so your team can apply and reverse changes.
  • Walk your developers through applying the recipe on a staging site and record the sign-off in the handover pack.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer, with scope agreed in writing.
  • Review recipes when Drupal core or a contributed module used by the recipe releases a version that changes its configuration.
  • Confirm recipe compatibility with your current Drupal version and plan updates alongside your core upgrade schedule.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com