Skip to main content

Drupal CMS Recipes: The Real Building Block for AI-Driven Site Assembly

· 5 min read
Victor Jimenez
Software Engineer & AI Agent Builder

Drupal CMS recipes are the most practical building block for AI-driven site assembly: they translate a plan into installable modules and configuration with one apply step. I built a small recipe package and a PHP blueprint helper to test how well this works in practice.

The Pitch

"Recipes are Composer packages of type drupal-recipe meant to be unpacked and applied, not kept as runtime dependencies."

— Drupal Recipes Initiative, Author Guide

This is the key insight. Recipes are not modules. They are disposable install instructions that configure your site and get out of the way. That model is exactly what AI site builders need: emit a recipe, apply it, done.

Context

The Recipes initiative APIs are available in core as experimental in Drupal 10.3+ and Drupal 11. Applying a recipe happens from the webroot via drush recipe (Drush 13+) or php core/scripts/drupal recipe. The core recipe-unpack workflow places recipes in a /recipes directory.

How Recipes Work

recipe.yml
name: "AI Site Builder Baseline"
description: "Installs a baseline site-building stack with AI Builder role."
type: "drupal-recipe"
install:
- node
- block
- views
- ai
config:
actions:
user.role.ai_builder:
createIfNotExists:
label: "AI Builder"
grantPermissions:
- "administer nodes"
- "access content overview"

Recipe Capabilities at a Glance

FeatureHow It Works
Module installationList modules under install key
Config creationcreateIfNotExists for config entities
Permission grantsgrantPermissions action on role entities
Simple config updatessimpleConfigUpdate for settings
Application methoddrush recipe (Drush 13+) or php core/scripts/drupal recipe
Package typedrupal-recipe — Composer package, not a module
Runtime dependencyNone — applied and discarded
Reality Check

Recipes are experimental. The API surface is evolving. If you build tooling that emits recipes, pin to a specific core version and test on every minor update. The "apply once and forget" model also means there is no built-in rollback. If a recipe installs the wrong module, you are cleaning up manually.

Full list of recipe config actions
  • createIfNotExists — Creates a config entity if it does not already exist
  • grantPermissions — Grants permissions to a role
  • simpleConfigUpdate — Updates simple configuration values
  • Config entity IDs are used as keys to target specific entities
  • Actions are expressed in recipe.yml under config.actions

The Code

View Code

What I Learned

  • Recipes are Composer packages of type drupal-recipe meant to be unpacked and applied, not kept as runtime dependencies.
  • Applying a recipe happens from the webroot via drush recipe (Drush 13+) or php core/scripts/drupal recipe, and the core recipe-unpack workflow can place recipes in a /recipes directory.
  • Recipe configuration actions live in recipe.yml and are expressed as config entity IDs plus actions like createIfNotExists, grantPermissions, and simpleConfigUpdate.
  • The Recipes initiative APIs are available in core as experimental in Drupal 10.3+ and Drupal 11.
  • For AI site building, recipes are the right abstraction layer. The hard part is not generating the YAML — it is validating that the generated recipe does what you intended.

Why this matters for Drupal and WordPress

Drupal recipes are the most practical path to AI-driven site assembly in the Drupal ecosystem — they let an AI agent emit a YAML file that installs modules and applies configuration in one step. This is architecturally different from WordPress's approach, where site scaffolding relies on wp-cli commands or starter themes. Drupal agencies building site factories or multi-tenant platforms should invest in recipe authoring now, as the pattern will likely become the standard distribution mechanism replacing install profiles.

References


Looking for an Architect who doesn't just write code, but builds the AI systems that multiply your team's output? View my enterprise CMS case studies at victorjimenezdev.github.io or connect with me on LinkedIn.