This project is not covered by Drupal’s security advisory policy.

Drush Recipes is a series of drush calls as well as a packaging format. The format side allows you to create a .drecipe file which is a series of drush calls that go together to have meaning on their own. This format can be saved and loaded from JSON, XML or YAML. There are several types of "ingredients" for chaining drush calls together like prompting the user to select between a list of recipes, supplying tokenized drush calls for input from the user, or straight up drush calls.

There are also advanced calls that build upon this concept to analyze sites (ddt), as well as short-hand methods for generating .drecipe files by recording your actions or using an interactive command prompt. Check out the latest posts on the project:

drush recipe commands

  • drush cook <recipe1>,<recipe2> - executes a series of recipes in the order they are received.
  • drush cook <recipe1> --mlt-token1=value1 --y - execute recipe1, automatically filling out madlib formatted recipes calling for [token1] to be given value1 (this overrides the default if token matches the default set)
  • drush @target1 ddt @target2 - automatically author a recipe for getting @target1's modules (enabled, downloaded, disabled) and variables (vset and vdel) the same as @target2. This creates a map for how to get from target1 to target2 which can then be cooked as one command! This allows for distro forking as a repeatable pathway / innovation by site builders and non-developers!
  • drush @target1 ddt @none - same as above but with no target defined you are saying "what would it take to go from nothing to this site" so it's effectively the distribution blueprints as 1 command!
  • drush dlr - returns a listing of all recipes that it finds.
  • drush dlr dr_security --more-detail - returns info just about the dr_security recipe
  • drush dwr - interactive terminal to author a new recipe file and save it to your recipe area! Great for getting started or quickly writing a "macro" instead of issuing a bunch of drush commands.
  • drush valid-recipe - validate that a recipe (or comma list) are validate recipes that are structurally correct (this is not auditing their functionality, just the recipes specification listed).
  • drush dvr start
    drush dvr pause
    drush dvr watch
    drush dvr delete --command=pm-status
    drush dvr save
    drush dvr save --test-run
    drush dvr stop
    - the DVR has lots of functions including start, stop, pause, delete, watch and save. Basically you can log all calls that you make via drush, massage what's been recorded, and then save it or stop (which turns off and then saves) what was typed to a recipe. This allows you to perform a bunch of changes in development via drush after turning on the dvr, then stopping the dvr and ripping those changes to a new recipe. This opens up an entirely new kind of lazy DevOps workflow!
  • drush drurl <location> - pull recipes down from a remote drush recipe hosting service.
  • drush @target drup target_to_filename /location - spider a `/location` for .drecipe files that include `target_to_filename` in their name, compare the timestamp to the last known time that site ran that target match (if it didn't, uses the site install stamp in all drupal sites). This effectively allows for predictable upgrading much like hook_update but without having to manually write code as the update can be boiled down to recipes / drush calls; further ensuring accuracy / transparency of what was run and in what order.
  • drush @target drup target_to_filename /location --replay-from=0 - start at 0 and reprocess every matching recipe in order
  • drush dwr --for-drup - write a recipe and append timestamp to the end since it will be for use with the drup command.

There are many recipes included out of the box when you download this project. Also you can build your own by following the API to utilize the more complex capabilities like Madlibs and environmental tokens.

These can either be chained together by commas as a single call OR embedded directly in other recipes so that they can be executed at the right point in the operation. This allows for creation of granular recipes as well as "cookbooks" essentially by nature of how it would process the commands.

An example recipe:

  "name": "Heighten security",
  "drush_recipe_api": "1.0",
  "weight": 0,
  "recipe": [
  "metadata": {
    "description": "Disable projects that cause issues, increase h-our defenses cap'in!",
    "version": "1.0",
    "type": "add-on",
    "author": "btopro"

These recipes can then be included in modules, themes, distributions or as stand alone functions which can complement .make files that you sometimes see included with modules and themes to get dependencies.

Modules - Provide sane defaults for other values in the system after installation without including "example" features to provide the strongarm settings.

example: RestWS typically requires an account be created with SERVICE_ as the prefix. create this account automatically and disable page caching settings to avoid the accidental caching of resource results.

Themes - Certain themes have known module / version conflicts or require other libraries / packages to work correctly. Themes don't have this capability in the same way that modules do.

example: Zurb Foundation requires jquery update (or something similar) and it to be set to 1.10+

Distributions - Package popular "additional" capabilities into recipes without including them by default. This is an area that "Apps" can possible fill but if you don't want to use a full-blown App server to manage these things, .drecipes can be a simpler alternative.

example: Open Atrium is typically run for intranets; provide simple 1 liners for the recommended methodology for properly securing that given a closed, company usage (secure pages, no user registration, ldap integration, example ldap integration).

Stand alone - "Our company standard post-build recipe" placed in version control or "the post build operations of moving from production to dev". Sure, people use Jenkins for these kinds of things, but not everyone has that workflow, they have a workflow "like" that but different. This can fill that niche.

You could essentially replace (most) of the things people hate about distributions with a series of well made recipe files. If granular enough they can be repurposed to other common tasks that you have so planning ahead is always a great idea. There are some examples included by default to get an idea of some nice things that are possible.


drush dl drush_recipes

Drush Recipes in the wild

If making recipes by hand, you can use services like to ensure that it's valid JSON.
Related projects

Supporting organizations: 
Developed, Implemented

Project information