# The Drush Bootstrap Process

When preparing to run a command, drush works by "bootstrapping" the Drupal environment in very much the same way that is done during a normal page request from the web server, so most drush commands run in the context of a fully-initialized website.

For efficiency and convenience, some drush commands can work without first bootstrapping a Drupal site, or by only partially bootstrapping a site. This is more efficient, because there is sometimes a slight delay involved with bootstrapping, especially in some of the later stages. It is also a matter of convenience, because some commands are useful to use even when you do not have a working Drupal site available to bootstrap. For example, you can use drush to download Drupal with `drush dl drupal`. This obviously does not require any bootstrapping to work.

Starting with Drush-5, the loading of configuration files is no longer closely tied to the drush bootstrapping process. All configuration files are now loaded upfront, during DRUSH_BOOTSTRAP_DRUSH, with the Drupal root and site configuration files being loaded in advance of the corresponding bootstrap phase. See `drush topic docs-configuration` for details on drush configuration files.

## DRUSH_BOOTSTRAP_DRUSH

Only bootstrap Drush, without any Drupal specific code.

Any code that operates on the Drush installation, and not specifically any Drupal directory, should bootstrap to this phase.

## DRUSH_BOOTSTRAP_DRUPAL_ROOT

Set up and test for a valid drupal root, either through the -r/--root options, or evaluated based on the current working directory.

Any code that interacts with an entire Drupal installation, and not a specific site on the Drupal installation should use this bootstrap phase.

## DRUSH_BOOTSTRAP_DRUPAL_SITE

Set up a Drupal site directory and the correct environment variables to allow Drupal to find the configuration file.

If no site is specified with the -l / --uri options, Drush will assume the site is 'default', which mimics Drupal's behaviour.

If you want to avoid this behaviour, it is recommended that you use the DRUSH_BOOTSTRAP_DRUPAL_ROOT bootstrap phase instead.

Any code that needs to modify or interact with a specific Drupal site's settings.php file should bootstrap to this phase.

## DRUSH_BOOTSTRAP_DRUPAL_CONFIGURATION

Load the settings from the Drupal sites directory.

This phase is analagous to the DRUPAL_BOOTSTRAP_CONFIGURATION bootstrap phase in Drupal itself, and this is also the first step where Drupal specific code is included.

This phase is commonly used for code that interacts with the Drupal install API, as both install.php and update.php start at this phase.

## DRUSH_BOOTSTRAP_DRUPAL_DATABASE

Connect to the Drupal database using the database credentials loaded during the previous bootstrap phase.

This phase is analogous to the DRUPAL_BOOTSTRAP_DATABASE bootstrap phase in Drupal.

Any code that needs to interact with the Drupal database API needs to be bootstrapped to at least this phase.

## DRUSH_BOOTSTRAP_DRUPAL_FULL

Fully initialize Drupal.

This is analogous to the DRUPAL_BOOTSTRAP_FULL bootstrap phase in Drupal.

Any code that interacts with the general Drupal API should be bootstrapped to this phase.

## DRUSH_BOOTSTRAP_DRUPAL_LOGIN

Log in to the initialiased Drupal site.

This bootstrap phase is used after the site has been fully bootstrapped. This is the default bootstrap phase all commands will try to reach, unless otherwise specified.

This phase will log you in to the drupal site with the username or user ID specified by the --user/ -u option.

Use this bootstrap phase for your command if you need to have access to information for a specific user, such as listing nodes that might be different based on who is logged in.

## DRUSH_BOOTSTRAP_MAX

This is not an actual bootstrap phase. Commands that use DRUSH_BOOTSTRAP_MAX will cause drush to bootstrap as far as possible, and then run the command regardless of the bootstrap phase that was reached. This is useful for drush commands that work without a bootstrapped site, but that provide additional information or capabilities in the presence of a bootstrapped site. For example, `drush pm-releases modulename` works without a bootstrapped Drupal site, but will include the version number for the installed module if a Drupal site has been bootstrapped.